more about programming style

[DHowell.ES at Xerox.ARPA]

Ok, let me clarify a few things here.  By "idioms", I mean a piece of
code in a language which can be directly translated into another piece
of code in that ame language and looks similar in syntax to the same
piece of code in many other languages.  This would include i++ for i = i
+ 1 and if((a=b)==c) for a=b; if (a==c).  Idioms are language-specific.
These are the idioms that I would avoid to make programs more readable.

Pointers are a programming feature, not necessarily specific to a
language.  While BASIC, FORTRAN, and APL don't have them per se, they
could be simulated using procedures/subroutines.  When confronted with
two different ways of doing something in two different languages, the
more understandable, the better.   A pointer is generally easier to
handle than a PEEK or POKE function.

Structured programming is basic to the understandability of a program.
If a language does not support structured programming, either the
language should not be used, or it should be used very carefully with
comments explaining the structure of the programming.

Of course comments are important to any program, but they're not always
all that is important to a good program.  Let me give a possible
scenario.

Let's say I am a person whose programming experience consisted a few
high school and college courses in Basic & Pascal.  Ok, now let's say I
have a problem that I want solved by a programmer.  The programmer comes
back to me with a program which doesn't do quite what I wanted.  Now
from the comments it looks like the program should work right.  The
problem is in the code.  Now the programmer goes off and tries to fix
it, thinking he knows exactly what I want.  But when he comes back with
the revised program, it still doesn't do what I wanted.  Now the
comments were not enough to understand why the program doesn't do what I
wanted.  Therefore I must look at the code ("Foul", I hear you say.
"What are you doing looking at his code; you're not an experienced C
programmer!"  Well who else can look at it, if the programmer can't fix
it himself?  At least I know what I want done).  The program turns out
to be a full of these strange little idioms, which I've never seen
before.  Luckily, some of the code is readable, so I hope that what is
wrong is in that.  Let's say the problem with the program is that a
variable is being incremented when it shouldn't be.  However I don't
know that the variable is being incremented because I see this cryptic
"stuff++" which I pretty much ignore because the code is full of things
like that which gets lost in the shuffle.  I'm lost, the programmer
doesn't know what's wrong, and we're stuck.

However if the program said "stuff = stuff + 1" or even
"increment(stuff)", I could say "Aha! I think I know why it's not
working. That variable 'stuff', why is it being incremented.  I don't
think it should be incremented".  The programmer removes that line, the
program is fixed, and we all live happily ever after.

I know this was a rather long story, but I had to get my point across
somehow.  Remember that the "I" in that story could be someone you will
be working for.

Dan