Re: [9fans] Coding layout query

Re: [9fans] Coding layout query

[presotto]

[-- Attachment #1: Type: text/plain, Size: 67 bytes --]

In my case, it makes the non-automatic scanner 'grep ^fn *.c' work.

[-- Attachment #2: Type: message/rfc822, Size: 2005 bytes --]

From: "Thomas Bushnell, BSG" <tb+usenet@becket.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Coding layout query
Date: Fri, 8 Mar 2002 09:59:46 GMT
Message-ID: <87r8mwc6bf.fsf@becket.becket.net>

andrew@mbmnz.co.nz (Andrew Simmons) writes:

> Not wishing to start a religious debate here, but I notice that in the
> Plan9 source code, the return type of a function is placed on a separate
> line from the function name when the function is defined:
> 
> int
> nurdge(int a)

The normal reason for this is that various automatic program scanners
will detect this formatting and know that "nurdge" is a function
definition.

Thomas

Re: [9fans] Coding layout query

[Boyd Roberts]

Andrew Simmons wrote:
> int
> nurdge(int a)
> ...
>
> whereas in the header file, the return type is on the same line:
> 
> int     nurdge(int)
> 

The contexts are different.  I think both styles improve readability.

However, prototypes should never have been invented.

brucee's cyntax et al were much better ideas.

Re: [9fans] Coding layout query

[ozan s. yigit]

andrew@mbmnz.co.nz (Andrew Simmons):

> Not wishing to start a religious debate here, but I notice that in the
> Plan9 source code, the return type of a function is placed on a separate
> line from the function name when the function is defined:
> 
> int
> nurdge(int a)

	[.. etc]


this is a fairly common style on many development groups i've been in.
[checking tilbrook code... yep] many O/S projects use that style as well.
eg. nmh, glib, gtk, gcc etc. it is the layout for gnu coding standard. 
[www.gnu.org/prep/standards_23.html#SEC23].

oz
---
xyzzy! nothing happens.

Re: [9fans] Coding layout query

[Thomas Bushnell, BSG]

andrew@mbmnz.co.nz (Andrew Simmons) writes:

> Not wishing to start a religious debate here, but I notice that in the
> Plan9 source code, the return type of a function is placed on a separate
> line from the function name when the function is defined:
> 
> int
> nurdge(int a)

The normal reason for this is that various automatic program scanners
will detect this formatting and know that "nurdge" is a function
definition.

Thomas

Re: [9fans] Coding layout query

[bwc]

[-- Attachment #1: Type: text/plain, Size: 48 bytes --]

/^nurdge/		-- to find the function in the code

[-- Attachment #2: Type: message/rfc822, Size: 2090 bytes --]

From: Andrew Simmons <andrew@mbmnz.co.nz>
To: 9fans@cse.psu.edu
Subject: [9fans] Coding layout query
Date: Fri, 08 Mar 2002 11:49:29 +1300
Message-ID: <3.0.6.32.20020308114929.009a27f0@pop3.clear.net.nz>

Not wishing to start a religious debate here, but I notice that in the
Plan9 source code, the return type of a function is placed on a separate
line from the function name when the function is defined:

int
nurdge(int a)

or even

static
int
nurdge(int a)

whereas in the header file, the return type is on the same line:

int	nurdge(int)

It's not a style I've seen before, even, if memory serves, in TPOP, and I
was wondering if it was purely a matter of taste, or whether there was some
perceived benefit to be gained from laying the code out in this way - I
find it rather disconcerting at present.

[9fans] Coding layout query

[Andrew Simmons]

Not wishing to start a religious debate here, but I notice that in the
Plan9 source code, the return type of a function is placed on a separate
line from the function name when the function is defined:

int
nurdge(int a)

or even

static
int
nurdge(int a)

whereas in the header file, the return type is on the same line:

int	nurdge(int)

It's not a style I've seen before, even, if memory serves, in TPOP, and I
was wondering if it was purely a matter of taste, or whether there was some
perceived benefit to be gained from laying the code out in this way - I
find it rather disconcerting at present.