None of what’s written here is cast in stone; at least not yet... Once there’s a lot of code it may be another story. Then again, we’re not going to reject a good patch on the basis of cosmetics; and if you find the guidelines below too disagreeable, go ahead and work the way it’s better for you. Just beware, though, that after you submit your code, the next time you look at it, it will have been converted to be stylistically consistent with the rest of the sources.

NOTE: Ideally, the best thing to do would be to have automatic formatting of the sources on download/upload. For download, the individual developer could customize formatting to taste; for upload, the format is restored to follow Deeplayer guidelines. Unfortunately, I don’t believe there’s an open source formatter out there that can be customized for blank line and blank space rules as the ones below. I’d be happy to be proven wrong.

• No blank lines within functions or class declarations.
• No blank lines between function definitions.
• No blank lines between variable declarations.
• Use blank lines between things of different natures: between include statements and namespaces, between namespaces and forward declarations, between forward declarations and class declarations, etc.

Rationale:

Blank space is a powerful means of expressing separation of concepts or purposes. I will therefore have to argue against it ...

Well, the thing is, a function should have a single purpose; so, if there’s a blank line inside a function, either it doesn’t belong there, or the function should be split and refactored.

Same kind of argument applies at other levels. Take, for instance, functions declared within a class: They all have one purpose in common: To deliver the services that the class advertises, while keeping the state of the class self-consistent.

But one might argue, for example, that public functions should be separated from private ones. That’s true, but then there’s the public: keyword, which is pretty short and does a good job of taking up a line (if you’ll let it).

Or we could argue for putting a blank line between queries and commands; but the thing is, segregating queries and commands is not always a good idea... void set_foo() and int get_foo() const are probably best kept together, next to void set_bar() and int get_bar() const.

However well intended, blank lines within class and function declarations tend to amount to wasted pixels on your expensive crt. Additionally, they draw attention to themselves... “Why is this block separated from this other one? Is there something I’m failing to see?”, which attention often proves to be less than justified. And they often preclude or disrupt a programmer’s attempts at getting a quick “bird’s eye view” of the nature of a class or the workings of a function.

• Place a space before the opening parenthesis of a cast, or of a pair of parenthesis enclosing a sub-expression within a larger expression.
• No space after function name and before the opening parenthesis.
• Place a space after opening the parenthesis of a function.
• Place a space before closing parenthesis of a function.
• No space after closing parenthesis of a function, and before semicolon or opening curly brace; unless followed by the ‘const’ keyword, exception specification, “ = 0;” or initializer list.

Rationale:

Imagine you see this:

    foo (bar) goo;

You can’t tell what’s going on. Is foo a function, and goo #defined as “const”? Or is foo(x) a macro that declares goo as a reference to a pointer to a bar type? Or is foo #define’d to “cout «” and (bar) a cast of goo?

My example is contrived, since it’s malformed to begin with; but even in the more common cases, when it is possible to disambiguate the situation, it still may take a few micrograms of neurotransmitters to do so. I’d much rather be sure that if foo is a function, I can count on seeing,

    foo( bar ) goo;

and then I only need to bang my head against the wall to figure out what goo is.... And that I can count on that a space before the opening parenthesis denotes that bar is a cast... (not that I hope to see that kind of cast very often...).

I also follow the function declaration rule for “if( ... )”, “for( ..., ..., ... )” and “while( ... )” statements. I have no particular rationale for it, except to say that I have a pretty hard time understanding code where “if”‘s are followed by blank spaces, so it boils down to that if code is submitted in the latter style, I’ll have to,

Ctrl-H : find

if (

replace

if( 

before I can even read it.

Blank space and operators:

• Binary operators should have a blank space on each side; except the comma operator, which should be followed but not preceded by a space.

Rationale: Improves readablility.

• Unary operators should have no space between themselves and their arguments.

Example:

   goo( !true, *pfoo, ++bar );

Rationale: Helps visualize precedence.

• Long expressions should have spaces where they help visualize precedence by separating operations with lower precendence. Use of spaces should never intuitively contradict C/C++ precedence rules.

Example:

    if( ++  foo+ bar<7  *  goo-1 )   //AAAGGGKKK... :-(
    if( ++foo + bar  <  7*goo - 1 )  //much better... :-)

Long expressions are best avoided, anyhow, as they cause difficulty tracking a problem when something within them fails to compile or throws an exception.

(Kind or OT, but... Please avoid postfix increment and decrement whenever possible; –specially within expressions.)

Example:

int foo()
{
    return bar;
}

Rationale:

Looks neat; easy to see where a block begins and ends; makes up for the lack of blank lines (see blank space above)

Feel free to discuss the subject matter of this wiki page at the Code Style and Standards Forum.