Path: utzoo!attcan!uunet!mcvax!hp4nl!htsa!fransvo
From: fransvo@htsa (Frans van Otten)
Newsgroups: comp.lang.c
Subject: Re: Standard Indentation etc.
Message-ID: <663@htsa.uucp>
Date: 12 Dec 88 18:30:33 GMT
Reply-To: fransvo@htsa.UUCP (Frans van Otten)
Organization: HTS A Amsterdam
Lines: 87

First, let me reply to Gordon Gross. What he writes comes down
to: "A programmer is most productive when he can write programs
the way he wants to, so: No Standards ! I will use MY style
throughout eternity."

That's fine if you, and nobody else, is going to debug/update/etc
your programs. But if someone else might want to take a look at
your programs, he/she will be grateful if you had considered the
item of readability.

Gordon also writes about a teacher of his, trying to enforce his
preferred style upon his students. I once had such a teacher, too.
I opposed him, too, but I used real arguments. Your dean, saying
such requirements have no bearing on a student's ability to learn
how to write good programs, is wrong. I think it is very important
that students learn to write maintainable programs. Or do you never
work with a program someone else wrote ?

Russ Nelson writes: K&R exhibits a consistent style. I agree,
because I think that's a very good thing. When I had this quarrel
with my teacher, I asked Dennis Ritchies opinion on this matter.
Answering me, he wrote:

  " I like the style used in the C book and in many Unix programs because
    I regard the {} as noise that is (for C) necessary; the indentation
    should show the grouping.  Also, I dislike unnecessary vertical space
    because it makes programs too hard to see at once.  Finally it is
    desired to edit programs conveniently.  Thus the { is on the same
    line as the  for  because then it does not take vertical space and is
    less obtrusive; the } is on a line by itself because if it were at the
    end of the last line of the group it would be hard to edit (e.g. add a
    line at the end of the group), even though it takes space.  It is
    indented the same as the  for  partly because then it lines up with the
    for  it completes, but mostly because that is my custom.
    
    Else  is placed below  if  because it is equally important; the two
    (or more, as in  else if ) branches are not all under control of the
    if  but are alternatives.
    
    I must say that rational arguments are not very persuasive.
    I find it hard to read styles other than my own but do not try
    to persuade people except by example.  I suspect your teachers
    request a certain style because it makes it easier for them to
    understand your programs. "

(I included this also in anwser to John Lawitzke; he writes: "K&R exhibits
a consistent style, although they never really discuss it in depth.")

Except the placing of the {} and the if-else I agree with this. The else
is *absolutely* not equally important as the if; it is only one of the
two alternatives (see my example with the switch-statement). Placing the
{} my way uses the same amount of vertical space and is more correct:

  while (1)         while (1){
    { first;                first;
      second();             second();
      etc;                  etc;
    }               }

How do you like this alternative, Gerald Hawkins ?

Doug Gwyn writes:

>   ... but it's wrong.  Consider
>        if (a > 10)
>          then putchar('1');
>               something();
>          else putchar('2');
>               somethingElse();

Sorry Doug, must I really tell you ? C programmers should know that
compound statements should *always* be surrounded by {}. When I see
something like this, I always look twice because I can't see *any*
{ or } at all.

>Steve Bourne used a lot of (more elaborate and more correct) macro
>definitions to make his C source code look more like Algol.  He was
>nearly universally cursed for having done so.

I'm not trying to make C look like any other language. I'm just trying
to keep my programs readable. As Henry Spencer writes: it is *not* all
just religion.
-- 
                         Frans van Otten
                         Algemene Hogeschool Amsterdam
			 Technische en Maritieme Faculteit
                         fransvo@htsa.uucp