🚀 go-pugleaf

In article <2921@enea.se> sommar@enea.UUCP(Erland Sommarskog) writes:
[ first he is quoting Richard Harter ]
>>Also relevant is the fact that I annotate every line, ala assembly language
>>code, unless it is too long to fit a comment field in.  Normal format is
>>a code field of about 40 chars wide and a comment field of about 35 chars
>>wide with all comments aligned.  As you may imagine, short names are more
>
>Good habit. You need a lot of discipline to keep them updated. 
>  Mine is about the opposite. I usually put a describing comment in the 
>procedure header, explaining parameters if their names doesn't say it all. 
>For local variables I add a describing comment, except the most trivial. 
>  The code itself does only contain comments if I do some special trick. 

I much prefer the latter style of commenting.  A single comment describing
what the next block of code is going to do, instead of a comment on every
line.  Some lines don't deserve comments, and some comments degenerate into
stating the obvious ( increment counter, or something like that ).

As to the original topic of variable names, I also prefer names that have
some meaning ( not just now, to me, but a year from now, and to someone
else to fully versed in my arcane knowledge ).  I must admit however that
I do hate typing all those letters, also, some variables don't deserve
meaningful names ( i.e. loop variables, use i and throw it away ).

Perhaps the biggest problem is calling it CODE in the first place,
who's idea was that anyways?

dan ( tektronix!reed!lclark!dan )	"Someday we'll put this place
					 on the map ... "
-- 
= == := |-) ;^)