Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!uunet!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.lang.c
Subject: Compilers and programming style (was Re: A question of style)
Message-ID: <564@mwtech.UUCP>
Date: 20 Dec 89 13:28:19 GMT
References: <547@mars.Morgan.COM> <1989Nov30.001947.14883@aqdata.uucp> <427@jhereg.Minnetech.MN.ORG> <31884@news.Think.COM> <490@nixba.UUCP
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 50

In article <1989Dec18.113539.10935@gdt.bath.ac.uk> exspes@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@mwtech.UUCP, voice: 49-(0)6151-6 56 83