more questions about efficient C code

[Bill Crews]

>>> Rubbish.  "Any experienced programmer should be able to understand that"
>>> really means "we know it's hard to read, but...".  The idea is to make
>> 
>>  No!, it does not mean that...

> It is entirely possible to understand the semantics of the code fully and
> still consider it unnecessarily obscure and hard to read.  The mark of a
> good programmer is that his code is *easy* to read, not just *possible* to
> read.  Using every obfuscatory feature of the language, perhaps in the
> (oft-mistaken) belief that it improves efficiency, and then pleading that
> "any experienced programmer should be able to understand that" is the mark
> of someone who doesn't understand what this business is about.

Henry, I have read a number of your postings about the "professionalism" of
code readability, and while I generally applaud and agree with you, there is
nevertheless a feeling I get whenever I read such an article that you
apparently believe that that which is most easily readable by one programmer
is also most easily read by another programmer.  I heartily disagree with
this notion (if it IS your notion).

My most heavily-used language before learning C was PL/I, which looks
much like C *structurally*, BUT without the side effects such as imbedded
assignments that C has.  Perhaps that is the reason I tend to agree with
your statements somewhat.  However, as I get more used to reading C of
various flavors, such constructs HAVE gotten easier for me to read, and they
may someday become easier for me than PL/I-style, if for no other reason than
familiarity.

I tend to target a programmer with a thorough knowledge of the language, but
I try to refrain from forcing that programmer to exercise his powers of
lexical analysis without warrant.  I do NOT assume that that programmer has
read a lot of AT&T code (a dubious distinction) or a lot of anybody else's
code, as you seemed to in a posting not long ago on the topic of indentation
style.  I gathered then that your feeling was that anyone who deviates from
K&R (and, I suppose, AT&T kernel default) style was being UNPROFESSIONAL
by doing so REGARDLESS of how readable one judged this style to be to his
targeted reading population.  Obviously, I disagree with this, perhaps
because I have programmed in C for years and have never done Unix kernel
work.  Without stating where I put my braces (I don't want to start any
more religious wars), I will state that they differ from K&R style, and that
they are positioned such that, in MY estimation, MOST human beings (not just
kernel hackers) that read it can adapt to it based upon NO assumption of their
C reading experience.  And, yes, I suppose I recommend this to others.

-- 

  /  \    Bill Crews
 ( bc )   Cyb Systems, Inc
  \__/    Austin, Texas

[ gatech | ihnp4 | nbires | seismo | ucb-vax ] ! ut-sally ! cyb-eng ! bc