Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!oliveb!pyramid!ctnews!starfish!jerry
From: jerry@starfish.Convergent.COM (Gerald Hawkins)
Newsgroups: comp.lang.c
Subject: Re: Standard indentation?
Message-ID: <846@starfish.Convergent.COM>
Date: 10 Dec 88 00:16:06 GMT
References: <1988Dec8.173158.11839@utzoo.uucp>
Organization: Convergent Technologies, San Jose, CA
Lines: 103

-
There are several main styles I have observed in my short experience with
C:

First, there is actually little disagreement on the basic idea of
indenting code within a loop.  How many spaces to indent seems to be
purely a function of the width of your terminal or printer and the depth
of nested loops.  Whether or not all indents should be the same amount is
never mentioned.  I use TAB = 2 spaces for complex stuff and 4 spaces for
simple stuff.

The next major thing is where to put your '{' and '}'s.  For example (pun
intended):

	for(a = 1; a < 27; ++a) 
	{
		...
		...
	}

OR,
	for(a = 1; a < 27; ++a) {
		...
		...
	}
Of these two, I prefer the former.  It keeps all the matching pairs in
the same column, where they are easy to locate.  It introduces more
whitespace, which makes the code look nicer and further identifies the
code within the loop.  The latter condenses the code slightly.  If one of
your objectives is "no function longer than 1 page", you may use the
latter form (but I won't like it).


Then  there is the matter of how you handle do-while loops:

	do
	{
		...
		...
	}	while (x != EOF);
OR
	do			/* while (x != EOF) */
	{
		...
		...
	} 	while (x != EOF);
OR
	x = 99;		/* junk value so x doesn't equal EOF to start off */
	while (x != EOF)
	{
		...
		...
	}

Here, the middle version is my favorite.  If the code within the while is
long (25 - 75 lines) and there are lots of do and while statements, it
can be confusing matching them if you use the "self-documenting" approach
in the first fragment.  The last fragment is crappy style, but I confess
to using it when I feel lazy.  I would NOT use it at work for others to
read/review.  BTW, the only difference between the 1st and 2nd examples
is that the second example has the condition repeated in a comment
prominently on the do - line.

Here is a confusing one:

Is it ever ok to use the form:
	if (a = b * 2 + 39)		/* intentional assignment within condition
	*/
		...

INSTEAD OF:
	a = b * 2 + 39			/* more normal */
	if (a)
		...
I say "no!"  The code is unsupportable.  EVERYONE who ever reads it will
assume it is a trivial error (and perhaps try to correct it).

There are tons more items of style I am learning for the first time,
like--
If I have a code fragment which is used in only one place in one program,
but it is very independent code (doesn't depend heavily on surrounding
code), should I put that code into a function?  If I do, it will add
(trivial) execution time, (trivial) additional stack usage, and (trivial)
size to the program.

When do you make the decision to use #define statements?

How much hard-coding is too much?

When do you decide to create a library (ie, anytime a function is shared
between two programs?  Only when you are certain it is rock-solid?  Only
if it is used by many programs and will probably be used by many more?

How do you decide how portable you want things to be?



Rainy Days and
Automatic Weapons Fire
Alway Get Me Down.

These opinions are mine.
Jerry.  (jerry@starfish.convergent.COM)
-----