Gerhard Fiedler wrote:
>> One finds more than 10 or 20 lines of code in a sub to be an 'ugly' sub,
>> another may use a complex, difficult to articulate metric that combines
>> many attributes of the sub in question before passing judgement.
>> Opinions may, and often, change as the 'beholder' becomes more intimate
>> with the object being assessed.
>
> Problems with this point of view arise when you start working together.
> Then it's more about what works best for all than what you personally 
> "just
> like". So far, my style of breaking down functionality into relatively
> easily understandable pieces and combining them in ways that make sense 
> for
> the structure of the programming language, its community and the target
> domain has been appreciated by coworkers. The spaghetti style of writing
> long-winded functions spanning hundreds of lines generally isn't that much
> appreciated -- even by the ones who write such code, the difference being
> that they often only realize what a pain it can be when they have to start
> working on someone else's code that's written like this :)
>
> Which is of course not to say that there is a single, "right" way. But
> there /are/ some things that are reasonably proven to work, almost like
> Ohm's "law".


^------ What he said. :)

I see a strong tendency among some engineers to dismiss proven code 
development and project management methodologies ("it's just another 
theory").

Computer science is still young (compared to, say, architecture), so its 
practice involves a lot of trial-and-error. However, it's starting to 
mature, and after 60 years enough experience had accumulated for us to know 
that certain things work, and certain ones do not. There are "truths" and 
"axioms" that appear to be timeless.

Personally, I find that it's a lot cheaper to learn from other programmers' 
mistakes, than my own. IMHO, the best thing any software developer can do to 
make himself more productive, is to read as many books on the subject of 
software development, as he can.

Sure, there needs to be a balance of theory and hands-on, but hands-on 
experience generally improves productivity very gradually, and the 
time/benefit curve quickly levels off. Knowledge of new/better ways of doing 
things, on the other hand, can sometimes cause improvements on the order of 
magnitude.

Best regards,

Vitaliy


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist