Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!ncar!tank!mimsy!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: C Style Guide
Message-ID: <9334@smoke.BRL.MIL>
Date: 11 Jan 89 08:29:28 GMT
References: <2657@ficc.uu.net> <350001@hpopd.HP.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23

In article <350001@hpopd.HP.COM> daves@hpopd.HP.COM (Dave Straker) writes:
>I, also am on the lookout for _any_ info on C style, and would be terribly
>grateful for any information/standards/etc. that anyone has.

The problem I have with C "style guides" (by the way, Plum Hall
publishes one) is that they tend to encourage the notion that
all one has to do is slavishly adhere to a set of rules and
good style will automatically result.  But really good code
requires careful thought, not just following rules.  For this
reason I would rather have C programmers read good tutorials
such as Kernighan & Plauger's "The Elements of Programming
Style" (2nd Ed.), even though the C language is not dealt with
directly in that book.  Koenig's "C Traps and Pitfalls" would
make a good follow-on for beginning to intermediate C coders.

Religious debates about the placement of braces may be fun,
but really, any such formatting style that is not too
outlandish can be dealt with a whole lot more easily than
code that is poorly conceived.  I don't care HOW you format
	char c;
	while ((c = getchar()) != EOF)
		putchar(c);
since this code is a bug waiting to happen from the outset.