What is the best coding style?

Submitted by charlie.collins on Wed, 07/10/2002 - 08:58

Tagged:

Development

What is the best coding style? This is a big debate sometimes, much like vi vs. emacs or tabs vs. spaces, but on a larger scale.

Personally I prefer the GNU style because I learned it first from a GNU software book and because I think it is the easiest to distinguish and read. GNU also has simpler rules, or at least I think so. With GNU its always 4 spaces, the brackets go on the line after the statement, and yes the brackets are themselves indented, as is the next block of code. GNU makes for larger files, yes, but the amount is trivial and when compiled in Java for example the spacing is irrelevant at runtime.

GNU Example:

if (condition)
    {
        doIt();
    }

Other more popular styles are BSD (sometimes known as Allman) and KnR. BSD is close to GNU in that brackets are on next line, not same line as statement, but they are not spaced. KnR is one of the most popular and is the standard that Sun recommends for Java. KnR is in my opinion the worst possible style. In KnR the bracket is placed on the same line as the statement, this gets ultra confusing in complicated nested code blocks.

BSD (Allman) Example:

if (condition)
{
    doIt();
}

KnR Example:

if (condition) {
    doIt();
}

The debate of course rages on, and always will, but the important thing that many overlook is that within a project or company ONE NEEDS TO BE PICKED AND ADHERED TO. Pick one, any one, and do it that way. Pick a style, a spacing or tab standard and keep it that way. Consistency is far more important than which is chosen. Note that the linked Netscape style sucks. It is not consistent, several methods are allowed (the or stuff was added later.) (And yes, if your developers have a different style they can write a script to format in their style and then change it back at checkin, etc.)

Well, of course GNU is the CORRECT style, and 4 spaces are the obvious choice, but for more on the subject check the linked pages.

tuxedo.org/~esr style doc

Add new comment

Comments

KnR rocks!!!!!

Submitted by Andy (not verified) on Wed, 07/10/2002 - 11:18.

I think it actually gives the most readible style while reducing the number of lines in your source. First off, I can't think of any language that cares about whitespace, so that is never an issue in terms of compile time/binary size. Secondly, the ease (or lack thereof) of interpreting nested code blocks has to do with indentation, not bracket placement. For instance:

if (foo) {
if (bar) {
for (i=0; i

lets try that code example again...

Submitted by Andy (not verified) on Wed, 07/10/2002 - 11:20.

Forgot the &ltpre&gt tags...

if (foo) {
  if (bar) {
    for (i=0; i<k; i++) {
      doThis();
      doThat();
    }
    i=j=k=0;
    foo *haha = (foo *)malloc(sizeof(foo));
  }
  else {
    return;
  }
}

Re: What is the best coding style?

Submitted by Pete Ryland (not verified) on Wed, 07/10/2002 - 11:48.

Bloody oath. Totally agreed Andy. Except for the else bit, which I would place like this:

} else {

I.e., all on one line.

Also, 2-spaces I like because I often have to edit code in an 80-column display, and (with meaningful variable/function names :) one can easily go past that.

As for languages that care about whitespace, the obvious example is python which I have grown to love over the past couple of years (which was totally unexpected).

Re: What is the best coding style?

Submitted by jeepmutt (not verified) on Wed, 07/10/2002 - 13:34.

nononononononono!
BSD. only. You are all ignorant fools for saying otherwise.
(This is a flame war, right?)
Anyway, I really don't like KnR. I like my little squigglies to line up. I do sometimes take this liberty:

if (foo) { dooFoo();}
else {dooBar();}

or similarly

try { foo();}
catch (Exception e) { bar();}

for quicky things (set()/get() methods too.)
Regardless, at my shop, we use whatever the hell the developer wants to. Royal pain in the ass. Hell, I'd even agree to KnR if every body would agree to it. And by way of penalty, violators would have to chip in a buck everytime they checked in a file that wasn't formatted properly. Draconian, possibly. Necessary with lazy bastards, definately.

Re: What is the best coding style?

Submitted by atrox (not verified) on Wed, 07/10/2002 - 14:12.

whoooaaa, flame war indeed. you are all wrong. GNU STYLE.

for me, Andy, the placement of the brackets DOES matter in terms of readability, not just the spacing (although admittedly the spacing is more important). i cant stand the KnR stuff with the bracket on the same line as the statement.

also what i meant about spacing and performance results was for stuff sent across the wire to the client (such as JS - previously here I had said PHP, which is server side tech, so obviously that was wrong and it doesn't matter in that case). For stuff sent to the client, the whitespace DOES matter.

but again, i am in the same boat as jeepmutt. i could live with any style, as long as we picked one and stuck to it. (thats where a quick formatting script comes in handy, take in whatever and format as you desire).

Re: What is the best coding style?

Submitted by Andy (not verified) on Wed, 07/10/2002 - 15:42.

I am just curious, what does KnR or other formats say about doing something like this?

Widget label;
label =
XtVaCreateManagedWidget
(
  "test",
  xmPushButtonWidgetClass,
  parent,
  XmNleftAttachment, XmATTACH_FORM,
  NULL
);

In other words, treating a function call like a code block? This type of formatting greatly increases readability, especially with those variable-argument function calls that can get huge. Does this fall in line with proper coding style?

Re: What is the best coding style?

Submitted by atrox (not verified) on Thu, 07/11/2002 - 08:32.

Yes, there are guidlines in the various standards for exactly this scenario. If the arguments when you code the function itself or call the function are enormous then placing them on the next line, each on its own line, as you have displayed is recommended. In fact KnR recommends this for expressions as well.

KnR actually states this:

"If the expression will not fit on a single line.

Break after a comma.
Break before an operator.
Prefer higher level breaks to lower level breaks.
Align the new line with the beginning of the expression at the same level on the previous line.
If the above rules lead to confusing code or to code that's squished up against the right margin, just indent 8 spaces instead.

Personally I hate these rules, but I do agree with breaking but the KnR "align with the beginning of the expression" I dont like. I prefer that the params, args, expression statements, line up as in your example (with 4 spacing indentation of parens also of course ;).

Sun pretty much uses KnR, here is the guide:
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

and here is the page with above stuff: http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#248