Section 17. Style

17.1:   What's the best style for code layout in C?

A:      K&R, while providing the example most often copied, also supply
	a good excuse for disregarding it:

		The position of braces is less important,
		although people hold passionate beliefs.
		We have chosen one of several popular styles.
		Pick a style that suits you, then use it
		consistently.

	It is more important that the layout chosen be consistent (with
	itself, and with nearby or common code) than that it be
	"perfect."  If your coding environment (i.e. local custom or
	company policy) does not suggest a style, and you don't feel
	like inventing your own, just copy K&R.  (The tradeoffs between
	various indenting and brace placement options can be
	exhaustively and minutely examined, but don't warrant repetition
	here.  See also the Indian Hill Style Guide.)

	The elusive quality of "good style" involves much more than mere
	code layout details; don't spend time on formatting to the
	exclusion of more substantive code quality issues.

	See also question 10.6.

	References: K&R1 Sec. 1.2 p. 10; K&R2 Sec. 1.2 p. 10.

17.3:   Here's a neat trick for checking whether two strings are equal:

		if(!strcmp(s1, s2))

	Is this good style?

A:      It is not particularly good style, although it is a popular
	idiom.  The test succeeds if the two strings are equal, but the
	use of ! ("not") suggests that it tests for inequality.

	Another option is to use a macro:

		#define Streq(s1, s2) (strcmp((s1), (s2)) == 0)

	See also question 17.10.

17.4:   Why do some people write if(0 == x) instead of if(x == 0)?

A:      It's a trick to guard against the common error of writing

		if(x = 0)

	If you're in the habit of writing the constant before the ==,
	the compiler will complain if you accidentally type

		if(0 = x)

	Evidently it can be easier for some people to remember to
	reverse the test than to remember to type the doubled = sign.
	(Of course, the trick only helps when comparing to a constant.)

	References: H&S Sec. 7.6.5 pp. 209-10.

17.5:   I came across some code that puts a (void) cast before each call
	to printf().  Why?

A:      printf() does return a value, though few programs bother to
	check the return values from each call.  Since some compilers
	(and lint) will warn about discarded return values, an explicit
	cast to (void) is a way of saying "Yes, I've decided to ignore
	the return value from this call, but please continue to warn me
	about other (perhaps inadvertently) ignored return values."
	It's also common to use void casts on calls to strcpy() and
	strcat(), since the return value is never surprising.

	References: K&R2 Sec. A6.7 p. 199; Rationale Sec. 3.3.4; H&S
	Sec. 6.2.9 p. 172, Sec. 7.13 pp. 229-30.

17.8:   What is "Hungarian Notation"?  Is it worthwhile?

A:      Hungarian Notation is a naming convention, invented by Charles
	Simonyi, which encodes information about a variable's type (and
	perhaps its intended use) in its name.  It is well-loved in some
	circles and roundly castigated in others.  Its chief advantage
	is that it makes a variable's type or intended use obvious from
	its name; its chief disadvantage is that type information is not
	necessarily a worthwhile thing to carry around in the name of a
	variable.

	References: Simonyi and Heller, "The Hungarian Revolution" .

17.9:   Where can I get the "Indian Hill Style Guide" and other coding
	standards?

A:      Various documents are available for anonymous ftp from:

		Site:                   File or directory:

		ftp.cs.washington.edu   pub/cstyle.tar.Z
					(the updated Indian Hill guide)

		ftp.cs.toronto.edu      doc/programming
					(including Henry Spencer's
					"10 Commandments for C Programmers")

		ftp.cs.umd.edu          pub/style-guide

	You may also be interested in the books _The Elements of
	Programming Style_, _Plum Hall Programming Guidelines_, and _C
	Style: Standards and Guidelines_; see the Bibliography.

	See also question 18.9.

17.10:  Some people say that goto's are evil and that I should never use
	them.  Isn't that a bit extreme?

A:      Programming style, like writing style, is somewhat of an art and
	cannot be codified by inflexible rules, although discussions
	about style often seem to center exclusively around such rules.

	In the case of the goto statement, it has long been observed
	that unfettered use of goto's quickly leads to unmaintainable
	spaghetti code.  However, a simple, unthinking ban on the goto
	statement does not necessarily lead immediately to beautiful
	programming: an unstructured programmer is just as capable of
	constructing a Byzantine tangle without using any goto's
	(perhaps substituting oddly-nested loops and Boolean control
	variables, instead).

	Most observations or "rules" about programming style usually
	work better as guidelines than rules, and work much better if
	programmers understand what the guidelines are trying to
	accomplish.  Blindly avoiding certain constructs or following
	rules without understanding them can lead to just as many
	problems as the rules were supposed to avert.

	Furthermore, many opinions on programming style are just that:
	opinions.  It's usually futile to get dragged into "style wars,"
	because on certain issues (such as those referred to in
	questions 9.2, 5.3, 5.9, and 10.7), opponents can never seem to
	agree, or agree to disagree, or stop arguing.