Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!husc6!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: Why NULL is 0
Message-ID: <784@cresswell.quintus.UUCP>
Date: 18 Mar 88 07:01:41 GMT
References: <2550049@hpisod2.HP.COM> <7412@brl-smoke.ARPA> <3351@chinet.UUCP> <25652@cca.CCA.COM>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 33

In article <25652@cca.CCA.COM>, g-rh@cca.CCA.COM (Richard Harter) writes:
> I don't know if this is what ANSI C expects, but it's not too hot if
> it is, because we now have two descriptions of the calling sequence.
> The right thing is simply
> 
> #include "prototypes.h"
> ....
> type_of_foo foo(a,b) {....}
> 
> In fact, even type_of_foo should be omitted, since that is really part
> of the description.
> 
It depends what you mean by "the right thing".
If you mean "whatever means I have less to write", fine.
If you mean "whatever makes C more like Pascal", fine.
If you mean "whatever will make the code easier to maintain",
you're dead wrong.

When as Joe Maintainer I come along and try to figure out what your function
foo() does, I want to be able to see what the arguments and result are,
which means that I want them *right* *there* with the rest of foo(), where
I can see them.  In fact, I want all the immediately useful information to
be there where I don't have to hunt all over file space to find it.
(Note that I said *immediately* useful.  If there are 10 pages of text
describing the thing, and a couple of hundred test cases, give me in the
source code the names of the files that contain them.)

This was one of the biggest blunders in Pascal:  if you declare a procedure
'forward' in Pascal, you don't even get the NAMES of the parameters at the
actual definition.  Which meant that competent Pascal programmers always
put a copy of the parameter list there as a comment.

This is one of the things the ANSI C committee got right.
There are a lot of such things.