Kernighan and Pike's book: a flame

[ajs]

> As a matter of my opinion, the coding style in K&P's book isn't as bad
> as hpfcla!ajs led me to believe.  The hoc functions are small and each
> one is identified with a comment.  The functions seem to perform atomic
> actions, so commenting within them doesn't seem necessary.  Worse than
> no comments are "a++; /* increment a */" comments.

Hmmm...  I'll be more  specific.  Opening to page 341 (at random, in the
hoc  listing) we find a short  header  (three  lines)  followed by seven
short  procedures.  Only one  procedure  has a summary  comment, a brief
one.  There are no bold  headers to separate  and locate  routines,  nor
comments to summarize the purpose of each  routine, how it fits into the
overall  scheme,  what it's  limitations  are, etc.  On the whole page I
count three blank separator lines.  There are very few comments and they
are  quite   cryptic.  Variable  names  like  "d"  and  "fp"  are  used.
Expressions are run together without blanks.

This is  clearly  one code  fragment  that could  benefit  heavily  from
ergonomic improvements in style, commenting, layout, vertical alignment,
etc.  Unfortunately, it's typical of the book.

> Code must be commented (and written!) with care.  We should be arguing
> about quality rather than quantity.  I think K+P's book was written
> with quality in mind and in execution.

So who's  yelling for  quantity  over  quality?  I agree, their book was
written with that in mind.  My flame was and is that they did not go far
enough.

In my opinion, all  programmers  are human  beings, and all human beings
are  imperfect,  and lazy too.  That  includes  me.  But, I strive, as a
professional  software  designer, to make my software as "perfect" as it
can be -- bug-free, ergonomic,  portable, even pretty.  I have two great
frustrations:

(1) With  such an  attitude  you find  yourself  continually  improving.
Yesterday's  code  is  always  an   embarrassment,   lacking   "obvious"
improvements.  Being human, you can never even come close to perfection.
People can always find flaws in your code.

(2) Most other  people care far less about their  overall code  quality,
and I often have to maintain it.  Arggghhh...

Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado
{ihnp4 | hplabs}!hpfcla!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"