|
|
|
|
|
by kenbot
4398 days ago
|
|
Hi Manicdee! The point is that with any unityped representation you can come up with, the name tells you nothing certain; any conclusions you think you can draw from it are pixie-dust and moonshine. Even with nonsense names, the argument and return types give you solid proof not only about what the method does, but importantly what it _doesn't_ do. There's no criticism implied of my colleagues at all -- I'm as culpable as anyone. The point is though, we can make big improvements with types, without paying a big cost. You must have had good OOD teachers:
http://c2.com/cgi/wiki?CaseStatementsConsideredHarmful
http://c2.com/cgi/wiki?SwitchStatementsSmell Cheers |
|
Do I fight management to get the two weeks I'll need to write feature X correctly, or just take the obvious shortcuts to get it done in 1 week?
Of course my laziness shows through because I haven't been in management's ear for long enough beforehand that they decided to give me one week without consulting with me ;)
I display this "lack of bottom-up management" failure mode consistently, I'm more interested in writing code :\
As for my OOD teachers, I've had mountains of bad Perl and PHP code to wade through, and the benefit of Stack Overflow and the Django Project to guide my thinking on the matter.
Type systems do provide some compiler-level assistance in the march towards coherent, well designed software, but they won't solve problems like
When you provide the top_left of the wrong element (e.g.: confusing the top left of the drawing space with the top left of the window or display area.