Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC830713); site edai.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!houxm!hogpc!houti!ariel!vax135!ukc!edcaad!edee!edai!ok
From: ok@edai.UUCP
Newsgroups: net.lang.c
Subject: return (messy) -vs- return clean
Message-ID: <4191@edai.UUCP>
Date: Tue, 22-May-84 16:45:48 EDT
Article-I.D.: edai.4191
Posted: Tue May 22 16:45:48 1984
Date-Received: Thu, 17-May-84 03:45:13 EDT
Organization: Art.Intelligence,Edin.Univ.
Lines: 30


    I never use return(expr) or return (expr) on the grounds that
it looks like a FUNCTION CALL, and it isn't.  Most of the time
you are saying return TRUE or return FALSE or return <variable>,
and the extra junk doesn't do anything for you.

    Do people who like return(e) also #define Goto(x) goto x
and then write Goto(L), Break(), Continue() and so on?  If not,
why not?

    I'd prefer keywords like if ... then instead of if (...).
This principle that things which aren't function calls shouldn't
look like function calls has lead me to adopt the practice of
	#define skip
	while (this_does_everything) skip;
instead of
	while (this_does_everything) ;
I apologise for letting code get out into the world without this
readability feature, and promise not to do it again.

    In all seriousness, the more parentheses there are in an
expression, the harder it is to read.  I personally find the
layout
	y = x == 5 ? 1 : 0;
much clearer than
	y = (x == 5) ? 1 : 0;
Yes, a policy of avoiding parentheses can make very large expressions
hard to read, but adding unnecessary parentheses only makes it worse;
the answer is to break up big expressions.  (That doesn't hurt most
compilers either.)