proper c source coding standard - style changes?

proper c source coding standard - style changes?

[David C. Rankin]

Listmates,

	First post, and more of a curiosity than a problem. Years ago I worked 
extensively with c, fortran, etc. (late '80s, early 90s). I do my own office 
infrastructure/networking/groupware, etc. all with linux and open source 
software. Occasionally that requires me to dust off my programming tools to 
tweak this or that to work in my setting. Most recently a bit of c with the 
mysql connector. In doing so I have noticed one big change to the way source 
files are now formatted.

	When I grew up doing this your source files and functions would normally be 
laid out in this order:

#include <headerfile.h>

void function ();    // function headers defs
int *function ();

int main () {
	do something;
	return 0;
}

void function () {
	stuff;
}

int *function () {
	stuff;
}

	Now I see through much of the glibc documentation and other sources a layout 
like this:

#include <headerfile.h>

void
function ()
{
	stuff;
}

int *
function ()
{
	stuff;
}

int
main ()
{
	do something;
	return 0;
}

	And, yes, I know it doesn't matter to the compiler, but as I said I was 
curious. Has there been some type of recommended standard for doing it in this 
way, or is it just more of a some people like chocolate ice cream versus 
vanilla issue? In the olden days, IIRC, the logic was that you wanted to see 
the most important part of your code up top -- the main function, without 
having to wade through all the function bodies before you got to it. With the 
new layout, you don't have to worry about an additional function def up top 
with eliminates the chance of typos and makes changes easier. So I see the 
benefits of both.

	Also, if this is some type of flame war issue like vi/emacs, I apologize in 
advance, I am not aware of its sensitivity, I'm just curious and like to 
follow the "recommended" standard in case somebody has to read my code in the 
future. Thanks.

	All I'm looking for is either a (yep there was a new recommendation, here's 
the link) or a (it's a chocolate or vanilla thing). 

-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: proper c source coding standard - style changes?

[Philip Herron]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David C. Rankin wrote:
> Listmates,
>
> First post, and more of a curiosity than a problem. Years ago I
> worked extensively with c, fortran, etc. (late '80s, early 90s). I
> do my own office infrastructure/networking/groupware, etc. all with
> linux and open source software. Occasionally that requires me to
> dust off my programming tools to tweak this or that to work in my
> setting. Most recently a bit of c with the mysql connector. In
> doing so I have noticed one big change to the way source files are
> now formatted.
>
> When I grew up doing this your source files and functions would
> normally be laid out in this order:
>
> #include <headerfile.h>
>
> void function ();    // function headers defs int *function ();
>
> int main () { do something; return 0; }
>
> void function () { stuff; }
>
> int *function () { stuff; }
>
> Now I see through much of the glibc documentation and other sources
> a layout like this:
>
> #include <headerfile.h>
>
> void function () { stuff; }
>
> int * function () { stuff; }
>
> int main () { do something; return 0; }
>
> And, yes, I know it doesn't matter to the compiler, but as I said I
> was curious. Has there been some type of recommended standard for
> doing it in this way, or is it just more of a some people like
> chocolate ice cream versus vanilla issue? In the olden days, IIRC,
> the logic was that you wanted to see the most important part of
> your code up top -- the main function, without having to wade
> through all the function bodies before you got to it. With the new
> layout, you don't have to worry about an additional function def up
> top with eliminates the chance of typos and makes changes easier.
> So I see the benefits of both.
>
> Also, if this is some type of flame war issue like vi/emacs, I
> apologize in advance, I am not aware of its sensitivity, I'm just
> curious and like to follow the "recommended" standard in case
> somebody has to read my code in the future. Thanks.
>
> All I'm looking for is either a (yep there was a new
> recommendation, here's the link) or a (it's a chocolate or vanilla
> thing).
>
I take it you haven't done much programming, take a look at any
project on the net they all have their own code formatting preferences
for whatever helps _you_ read your code. This should probably be moved
to gcc-help...

A benefit of using the bottom formating is you don't need to keep
prototypes for the extra functions if they are being called by main.

Try not to ask questions like this in GCC, GCC-help is for help on
using gcc etc.

- --Phil
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqZ2b0ACgkQAhcOgIaQQ2GJ4QCfXCtFIHeDfYIhoVAbMQNiEV/P
WVIAn2/61h/MwEb0f4LTdVnnZXwarbNo
=6paS
-----END PGP SIGNATURE-----

Re: proper c source coding standard - style changes?

[David C. Rankin]

On Saturday 29 August 2009 08:45:37 pm Philip Herron wrote:
<snip>
> 
> Try not to ask questions like this in GCC, GCC-help is for help on
> using gcc etc.
> 
> --Phil
> 

Sorry Phil,

	I read the guidelines at http://gcc.gnu.org/lists.html before I posted. The 
guidelines say:

<quote>
Open lists:

    * gcc-help is a relatively high volume list for people searching for help 
in building or using GCC.

    * gcc is a high volume list for general development discussions about GCC. 
Anything relevant to the development or testing of GCC and not covered by 
other mailing lists is suitable for discussion here.
</quote>

	I didn't see the distinction, and I'm still not sure I do. But I know now, 
posts about general code layout questions go to the help list. Thanks.


-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: proper c source coding standard - style changes?

[Dave Korn]

David C. Rankin wrote:

>     * gcc-help is a relatively high volume list for people searching for help 
> in building or using GCC.
> 
>     * gcc is a high volume list for general development discussions about GCC. 

> 	I didn't see the distinction, and I'm still not sure I do. 

  By "about GCC", it means exactly that: development discussions about GCC,
the compiler itself, and not about the programs that it may be used to
compile.  So questions for this list tend to be along the lines of "How do I
add a new optimisation pass" or "How can I port GCC to generate code for a new
CPU", and not about the more general end uses to which the compiler is put,
nor about general programming themes and discussions.  Hope that clears it up
a bit.

    cheers,
      DaveK

Re: proper c source coding standard - style changes?

[David C. Rankin]

On Saturday 29 August 2009 10:17:57 pm you wrote:
> David C. Rankin wrote:
> >     * gcc-help is a relatively high volume list for people searching for
> > help in building or using GCC.
> >
> >     * gcc is a high volume list for general development discussions about
> > GCC.
> >
> > 	I didn't see the distinction, and I'm still not sure I do.
>
>   By "about GCC", it means exactly that: development discussions about GCC,
> the compiler itself, and not about the programs that it may be used to
> compile.  So questions for this list tend to be along the lines of "How do
> I add a new optimisation pass" or "How can I port GCC to generate code for
> a new CPU", and not about the more general end uses to which the compiler
> is put, nor about general programming themes and discussions.  Hope that
> clears it up a bit.
>
>     cheers,
>       DaveK

DaveK,

	That was an excellent explanation of the scope of topics for the list. Since 
most of my programs tend to be less than about 250 lines and use less than 3-4 
parsing passes with loops operating on file or pipe buffers, I don't think 
I'll have to much to add concerning the fine points of compiler optimization 
;-) I'll be vigilant concerning the topic. Thanks again for the guidelines 
explained. What wouldn't be a bad addition to the list subscription page as 
well.

-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com