Re: Reading great code

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Well, if all this debate, each person making some excellent points, and
almost all at odds with one another over those very points, doesn't point up
the greatest difficulty of mastering programming, I don't know what will.

In fact, I view the whole thing as a balancing act. Elegant software is a
beautiful thing to behold, and just as rare. For one thing, it just takes
too long to write, and we developers are constrained by time and money
considerations. Reusability is also a double-edged sword, and although I
believe John and Jon are both correct, their conflict is more one of
emphasis than perhaps they realize.

The real trick is to master skills that enable one to stay more or less
within the limits of what *can* be achieved, and that perfection that any
conscientious programmer desires to achieve in his/her work. Every developer
finds his/her own unique methodology to strive towards that "golden mean,"
and each is unique because we all have a unique combination of gifts and
liabilities.

All that said, reading "good" code is always a good idea. As for "great"
code, it's hard to draw the line between the 2, and even reading "bad" code
can be a worthwhile process, as long as one is looking at it as "bad." One
can observe and learn from the pitfalls that others have fallen into, as
well as from the examples of those who have attained a measure of skill.

The most important aspect of a programmer's personal development is the
drive to become perfect, a goal which, although impossible to attain, is
worth aiming at. What you seek is what you get, in the long run. Aim for the
stars, and someday, you'll at least reach the moon.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com

A man, a plan, a canal, a palindrome that has.. oh, never mind.

"John Browning" <no_spam@xxxxxxxxxxx> wrote in message
news:ewdbKg57GHA.4632@xxxxxxxxxxxxxxxxxxxxxxx
Robust I can agree with. Reusable less so - because in my experience,
the more reusable and generic you make it, the more complex it has to
be in order to accomplish the one task you have at hand. I often find
that I then never reuse the component in question, having gone to all
the trouble of making it reusable. These days, I build things in a less
reusable way until I can see that I've got code which *could* be reused
with a bit of a tweak. At that point with the appropriate unit tests in
place, it's usually not too hard to make the changes while keeping the
original use working.

If you know for sure that you actually need the code to be generic from
the start, that's a different matter of course.

This is often known as "YAGNI": "You Ain't Gonna Need It"

I couldn't disagree more :) The correlation between generic software and
successful software is simply overwhelming. When things are written
generically from the outset (and properly documented), you soon end up
with
<snip>


.