C Indentation Survey Results (long...)

Craig Miller dcm at busch.UUCP
Tue Apr 16 22:24:19 AEST 1985


[ warning: slight flame ahead... ]

In <9930 at brl-tgr.ARPA> cottrell (jim cottrell) writes:

> This would never happen if funxions were wholly on one page and form 
> feeds were used to keep it that way. Let's get modular.

	Since when does modularity mean functions wholly on one page?
	Are you implying that when you get close to the end of a page,
	you just split your current function off into 2 functions so
	that they'll fit on separate pages?  Yep, that's real modular,
	alright (sigh).  Here I was under the impression that modularity
	had more to do with what the functions *did*, not how they looked
	on a printout...  Guess I was wrong.

> Well, my choices were preferred by a factor of two to one. I can even 
> accept putting the brace on a separate line, but the others are JUST 
> PLAIN STUPID! Flexibility breeds indecision. I read a quote that said
> "Dennis Ritchie is to be commended for shepherding C programmers down
> a narrow path". Amen! Do it his way.

	"JUST PLAIN STUPID"?  Real open minded, aren't we Jim?  What ever
	happened to programming style (as in everyone has their own...).
	This paragraph sounds like an argument for Fortran or (yuch) COBOL.
	"There is only one right way you can do it (or at least should be
	doing it)." Yep.  Here I thought one of strengths of C was it's
	flexibility to differing programming styles.  I personally think
	that when it comes to readability in a program, a big part is
	consistency.  If the person's indentation is 2 spaces, fine.  Just
	as long as they're consistent about it, I can read it (usually :-).
	But, guess I was wrong again.

> Actually, the way it SHOULD have been defined is
> 
> 	IF a==b THEN
> 		statement
> 		statement
> 	ELSE
> 		statement
> 		statement
> 	END

	Fine.  If you like it this way, use the preprocessor.  But I
	personally like C better than Algol (at least I think it's
	Algol...).  Do you actually find the Bourne shell source more
	readable than straight C?  Hmmm...  Algol background, eh?

> Where have you been? Tabs ARE 8 spaces. Ever since DEC (were they the 

	I thought a tab(tm of Coke) was one of those 'hardware dependent'
	type of things.  Just because DEC did it that way means it's
	right?  Fine.  This means VMS(tm of DEC) is the only os, right? :-)

> In your defense, however, I note that K&R is formatted with indentations
> of five spaces. This is probably due to the fact that it was typeset by
> printers, who traditionally interpret tabs as five spaces, as do typists.

	Or maybe if K&R had indented with 8 spaces, some of the lines
	wouldn't have fit on the pages?  Or maybe it's five because
	they did it on non-DEC hardware? :-)

> nonstandard tabs. Unfortunately, the tty & line printer drivers still
> interpret tabs as eight spaces.

	Yep.  But this is probably left over from the DEC-only days...

> altho one could argue against massive indentation as well.

	Another modularity argument?  I guess lines that are too long to
	stay on the screen aren't part of modular code, right?   Right.
	(heavy sigh...)

> To sum up, whenever there is more than one way of doing things, figure
> out a reason why one way is superior. For example, some brain-damaged

	What's superior to you is not always what's superior to anyone else
	(obviously).  Again, I think it's a matter of personal preference.
	And again, consistency is what matters the most (to me, at least).
	But then again, the 'preferred' way of { and } after `if', `for',
	etc. isn't consistent with the { and } when declaring functions,
	is it?  The style most consistent would seem to be:
		int a()
		{
			if (x)
			{
			}
		}
	right?  (Just for the record, my personal preference is:
			if (x) {
				}
	but I'd never try to push that onto anyone.  :-)

	Oh well.  Time to do some work.  Enjoy...

			just a lowly C programmer,

			Craig

p.s.	sorry for the length.
-- 
Craig Miller
..!ihnp4!we53!busch!dcm
The Anheuser-Busch Companies; St. Louis, Mo.



More information about the Comp.lang.c mailing list