why no "do : until"?

[Lloyd Zusman]

grey at despair.rpglink.com (Steve Lamb) writes:

> On Tue, 02 Jan 2001 23:41:14 -0500, Peter Hansen <peter at engcorp.com> wrote:
> >You are a cowboy-hacker type of programmer, not one working as a serious
> >software engineer in a group environment, right?  Or, if the latter, your
> >management just hasn't caught on yet.
> 
>     Actually, the latter and management has caught on.  They like
> the work I do.  That is because I don't spend days worrying about
> doing it one way or another when the difference is so miniscule that
> it isn't worth worrying over.
>
>     Like I said, how often is the code going to be changed versus
> getting the work done.  Idealism is fine and dandy as long as it
> doesn't get in the way of getting work done.  I'm firmly on the
> bazaar side, not the cathedral.  There is nothing wrong with that
> simple construct.  Nothing.  Only to those who do spend 3 days
> worrying about it instead of moving on to the next few hundreds of
> lines is there something wrong.

I agree that sometimes we can get overly nit-picky and miss the forest
for the trees.  However, I believe that software maintenance issues
are not within the realm of idealism at all, but rather, cold, hard
pragmatism.

I've been programming for over 30 years, and I have done and still do
my share of cowboy-style hacking.  There definitely is a time and a
place for this.  And I confess that the fastest and most enjoyable way
for me to write code is to cowboy-hack it, even though nowadays I only
do this for really quick-and-dirty one time hacks.

However, in addition to this kind of programming, I spend a lot of
time consulting to large corporations who have a staff of programmers
of varying abilities and levels of experience.  And there's a certain
level of turnover that is a normal part of IT departments, and also,
programmers sometimes get reassigned to new projects, get promoted,
get transferred, etc.  So over time, it's almost guaranteed that any
given section of production code will have to be maintained by someone
other than the person who originally wrote it.

And these large corporations have literally millions of lines of
software that are part of hundreds of applications that are constantly
being improved, upgraded, fixed, retired, rewritten, etc.  And I have
seen literally thousands of person-hours wasted when some old "legacy"
code couldn't be fixed or enhanced without an inordinate amount of
effort made in deciphering the intentions of the original programmers.

There's plenty of good code out there, but it's the bad code like this
which causes millions of dollars worth of person-hours to be expended
in trying to maintain it.  I am not exaggerating.  And so, there
definitely is a big, practical advantage that can be measured in
millions of dollars that can be gained by writing code that can easily
be maintained by the people who inherit it from the original authors.

And this is why I always try to be responsible and write code that's
maximally likely to be understood by someone with less experience than
I have, even though this means I lose some of the enjoyment of being a
cowboy most of the time.

Now, I'm not suggesting that we all become anal retentive.  As I
mentioned above, I agree that it's possible to be overly nit-picky and
miss the whole point.

I personally agree that the most clear and maintainable way to signal
an initial loop condition or a loop termination would not involve
initializing a variable that's used and changed within the loop to a
supposed out-of-range value.  The possible errors mentioned by the
others here are more likely to crop up in this scenario, especially
when a someone other than the original programmer has to start
maintaining the code.

But whether this is a deadly sin or not is another matter.  I can
think of certain restricted cases where it wouldn't be the end of the
world to do this, especially in short loops where this usage is being
clearly commented.  I wouldn't do this myself, but neither would I
fire a programmer if he or she wanted to code this way once in a
while, under the limited types of circumstances I mentioned.

But when working as a project leader in one of the large corporations
I've mentioned above, I would indeed fire (or refrain from hiring) an
otherwise good programmer who refused to make the effort to use
software constructs that facilitate the future maintainability of his
or her code.  As an employee of such a corporation, I would be causing
the company to lose lots of money if I allowed such a programmer to
work for the company.  And that would be irresponsible of me.



>     "Well, concpetually the variable means two things, blah, blah,
> blah, yap, yap, yap, yadda, yadda, yadda, yank, yank, yank."  I
> think my favorite was that one shouldn't init variables to arbitrary
> values.  I laughed a good few minutes for that one.  Should one init
> variables only to /random/ values?  That's the whole point of
> initing a variable, to set to to a known, arbitrary, value.

But you know damn well that the person who said that was not using the
word "arbitrary" as you're using it above, and therefore, you're
deliberately playing with words here, just to be argumentative.


>     It is like the people who are complaining about a valid while
> 1:break loop because it isn't obvious to the newbie maintainer.  Do
> you want a newbie maintaining your code in the first place?  No.  Do
> you want someone who is more worried about perfection in the code
> than working code?  No.

I agree: I neither want a newbie, nor a person who is more worried
about some platonic ideal of perfection than about creating practical,
working code.  But neither would I want someone who adamantly refuses
to make the effort to write code that is clear and easily maintainable
by the next good programmer who comes along to work on it.


>     Am I a "cowboy-hacker type of programmer?"  Better than either
> of the two extremes, so... yes.  

But as I stated above, those two extremes are not the only two
alternatives to being a "cowboy-hacker".  The third alternative (I
repeat) is to be a good programmer who is willing and able to write
code that can be quickly and easily understood and maintained by the
next good programmer who comes along.  There are plenty of programmers
like this in the world, and so if you came to me looking for a job,
you would lose out to someone else whose programming abilities are
equal to yours, but who also demonstrates that he or she understands
the importance of writing maintainable code.


-- 
 Lloyd Zusman
 ljz at asfast.com