Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!zaphod.mps.ohio-state.edu!mips!twg.com!dwh
From: dwh@twg.com (Dave W. Hamaker)
Newsgroups: comp.misc
Subject: Re: MEL - A *Real* Programmer
Keywords: Real Programmer, Hacker
Message-ID: <8187@gollum.twg.com>
Date: 31 Oct 90 04:26:57 GMT
References: <1990Oct23.235720.16178@nas.nasa.gov> <6089@nisca.ircc.ohio-state.edu> <54296@brunix.UUCP> <5777@suned1.Nswses.Navy.MIL>
Distribution: usa
Organization: The Wollongong Group, Palo Alto, CA
Lines: 25

zaft@nswses.navy.mil (Gordon C Zaft) writes:

>	The real solution, of course, is to make people write  a program,
>then, 3 years later, have them revise it.  For people that weren't
>around 3 years earlier, have them revise someone else's code.  This
>will provide first-hand evidence of why one should write clear,
>well-commented code.

It has been my experience, on code I don't have to worry about others having
to maintain, that documenting each program on the assumption I _will_ revisit
it years hence (verses the cost of spending a little longer reorienting myself
on those I actually end up revisiting) seems to require _more_ total time and
effort.  In short, your solution does not work for me.  That doesn't make me
feel superior either.  It makes it hard to decide how much commenting is
optimal, since I'm not writing them for myself as much as for whomever might
encounter my code later.  I think it is possible to go too far also, where
a comment can be less than useless, because it tells you nothing useful yet
you have to read it to find that out.  An example might be:

	++i;	/* increment the index variable */

Anyone else experienced this?

-Dave Hamaker
dwh@twg.com