public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "David C. Rankin" <drankinatty@suddenlinkmail.com>
To: gcc <gcc@gcc.gnu.org>
Subject: proper c source coding standard - style changes?
Date: Sun, 30 Aug 2009 14:56:00 -0000	[thread overview]
Message-ID: <200908291913.16587.drankinatty@suddenlinkmail.com> (raw)

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

             reply	other threads:[~2009-08-30  0:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-30 14:56 David C. Rankin [this message]
2009-08-30 16:12 ` Philip Herron
2009-08-30 18:42   ` David C. Rankin
2009-08-30 20:25     ` Dave Korn
2009-08-30 22:47       ` David C. Rankin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200908291913.16587.drankinatty@suddenlinkmail.com \
    --to=drankinatty@suddenlinkmail.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).