C programming style

[DHowell.ES at Xerox.ARPA]

Let me start out by saying that while I am not an experienced C
programmer, I am an experienced programmer.  These replies are based on
my limited knowledge of C, but I believe they are applicable to all
programming languages in one way or another.

>Ok, I give up!  Tell me how is it easier to find out what fp is when it
>is on a single line.  You find out what fp is by printing out its
value.
>You might also explain why someone would NOT want to reference fp again
>[In other words, why would you open a file for reading if you didn't
>want to read from it?]

If I am using a C interpreter, I could find out what fp is by printing
out its value.  However, when I am looking at the program on paper, and
I see the variable "fp" being used, I want to find out what fp is
representing.  If I see the statement "fp = fopen("foo", "r");", where
fp is at the beginning of a line then I know that fp is referring to the
file "foo".  But if I have to look for it in an if statement, then it's
that much harder to understand.  Sure I can understand it, and
"experienced C programmers" can understand it, but is everyone you're
working with an "experienced C programmer"?

>Typing has nothing to do with it, "i++" is clearer than "i = i + 1" to
me,
>especially (as someone else has pointed out) when 'i' is a longish
expression.

Maybe "i++" is clearer to you, but do you only write programs for
yourself?  To me "i++" is the kind of statement typical of an APL-type
language, not a language that is supposed to be structured and easy to
understand.  "i++" could mean something else in another language.  But
almost all high level languages (even APL) use some form of "i = i + 1"
to increment a variable.  If I want to distinguish between incrementing
and adding, then I would define a procedure such as "increment(i)",
which can be immediately understood.

If you completely understand the problem you're solving, and you are
working with no one but yourself, by all means use whatever cryptic
language idioms you want.  But if you are writing for someone else,
remember that the person who understands the *problem* may not
understand the programming language.  Do whatever you like as long as
you can explain it to the person who knows what he/she wants done.

Progams should be as language-independent as possible.  It shouldn't
matter whether the program is in C, Pascal, Ada, or even the dreaded
APL, but that it can be understood by *anyone* who needs to look at the
program.  If you limit that *anyone* to "experienced C programmers",
you're limiting the possibilities of that program.

Dan  /* comments are of course welcome */