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
next 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).