Use of i++; Re: C programming style

[Jerry Aguirre]

> 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.
.
.
> >Typing has nothing to do with it, "i++" is clearer than "i = i + 1" to
> >me,
.
.
> 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.
> Dan  /* comments are of course welcome */

Wants to define a "procedure" such as "increment(i)", claims to understand
C,  obviously doesn't!  Could be done as a macro but never as a procedure.

I have seen several projects coded in the "make it look like algol" style
of programming.  They define BEGIN to be { and END to be ;}, etc.  It always
seems to cause more trouble in the end than it saved.  By the time they
finished the project they are usually familiar enough with the language
that they no longer need these crutches.  Experienced C programmers get
frustrated trying to follow the code because there is always this extra
level of indirection that has to be verified as correct.  I have at
times refused to help users with "C problems" because figuring out
whether the syntax is correct requires reading a 300 line header file
that compleatly redefines the language.

No, increment(i) is not clearer than i++;  If I want to understand what
i++ means I only have to check the language spec.  Once I understand it
I know more about the C language.

If I come across an increment(i) then I am left in the dark.  Is this
built into the language, a "procedure" defined later in the code, in an
included file, from a library?  Is it defined correctly?  Does it
handle floats, longs, and ints?  How can it change "i" when C has call
by value?

And after I figure out what increment(i) does then I have learned how
one person coded one program.  When I work on someone elses code I have
to start all over and learn what "next(i)" does.

Writting clear code is like driving.  It doesn't matter whether you
drive on the left or right side of the road.  What matters is that you
drive on the side people expect you to.

If you want ease of maintenance then concentrate on USEFUL comments.  My
favorate non-comment is:
	int debug;	/* true if debugging is enabled */
or the ever popular:
	i++;	/* increment i */

Usually followed by a 3 page procedure with a cryptic name and no
comments.  I mean is it really hard to figure out what the variable
debug is used for?  I would really rather have a few lines at the top
of each procedure telling what it does and what the arguments are.  It
is usually easy to follow the code if you know why the procedure was
called.  It's trying to follow the code when you don't know what it was
called for or what its inputs are that is hard.

Languages don't write bad code, people do.

				Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry