Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site hp-pcd.UUCP Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!hp-pcd!hpfcla!ajs From: ajs@hpfcla.UUCP Newsgroups: net.unix Subject: Re: typedefs, etc. - (nf) Message-ID: <3746@hp-pcd.UUCP> Date: Mon, 9-Jan-84 03:33:53 EST Article-I.D.: hp-pcd.3746 Posted: Mon Jan 9 03:33:53 1984 Date-Received: Tue, 10-Jan-84 00:47:16 EST Sender: notes_gateway@hp-pcd.UUCP Organization: Hewlett-Packard, Fort Collins, CO Lines: 36 #R:cincy:-116500:hpfcla:43800003:000:1514 hpfcla!ajs Jan 7 16:34:00 1984 Sigh... I'm all for logical arguments, when they apply. (I'm all for posting to the right group, too, but you have to wade into battle where the action is.) Anyway, I'm convinced that there are few cases where purely logical arguments, without reference to human nature, result in software that IN PRACTICE is easier to maintain than otherwise. For example, someone stated that function parentheses are syntactically part of the function call, not the arguments, so you shouldn't leave a blank between the name and the left paren. Sounds good in principle, but which of these is easier to read? myfunc(arg1, arg2, arg3); /* barble one widget */ myfunc (arg1, arg2, arg3); /* barble one widget */ Like many people, I find that the left paren gets lost in the first case (everything up to the comma looks like one token). I suppose that: myfunc( arg1, arg2, arg3 ); /* barble it again */ might solve that problem if it weren't so opposite of English (it hides the function call and highlights the arguments). For similar reasons I like parens in returns, even if they are not required. They emphasize the "return" and enclose the value. Nevermind, it's hopeless, this is a religious issue! Just be consistent, whatever you do, and take pity on those who will support your code after you ascend to greater things. Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado {ihnp4 | hplabs}!hpfcla!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"