Compilers and programming style (was Re: A question of style)

[Martin Weitzel]

In article <1989Dec18.113539.10935 at gdt.bath.ac.uk> exspes at gdr.bath.ac.uk (P E Smee) writes:
[some lines deleted]
>I have a pathlogical dislike for the comma operator, because its most
>common use seems to be to allow overloading of too many unrelated concepts
>into one source line, in a sort of 'Gosh, amn't I clever' coding style.
>Banning it altogether is probably excessive, because I think there are
>occasions when it helps make things clearer or more efficient.  I do wish,

Agreed.

>though, that someone could put a heuristic into the compiler so that it
>would be rejected if it is being used because it is 'flash' rather than
>because it wins something in the context. :-)

Compiler writers look: His smiley tells, he doesn't really mean it!
Please don't put such stuff into your compilers - or make it optional
at least (!) - because *I* have a pathlogical dislike for compilers,
that do the following:

1. Example

	FILE *fp;
	if (fp = fopen("somefile", "r"))
		/* do somthing with fp */
	else
		/* handle errors */

	*** Compiler warning: "Do you mean equality?"

2. Example

	#if __STDC__ != 1
	#define const /*empty*/
	#endif

	*** Compiler error: "const will become a reserved word
		in future releases and may not be redefined"

Arrgh! I could continue here, but what I wanted to point out should
allready be clear: Some heuristics, a single compiler writer likes
(because it doesn't break his or her programming style) may strike
back on *many* others, who use perfectly legal constructs.

There should be other tools than the compiler, to control programming
style, from 'intelligent' beautifiers to proprietary style checkers,
but *please* leave the compiler to what K&R and ANSI allows.


-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83