Formatting Cplusplus

From ScorecWiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 16:16, 3 August 2010
Weisse (Talk | contribs)

← Previous diff
Revision as of 20:20, 19 August 2010
Weisse (Talk | contribs)
(Formatting Cpluspus moved to Formatting Cplusplus)
Next diff →

Revision as of 20:20, 19 August 2010

Contents

Length

Lines should not exceed 80 columns in length. Long lines should be broken up with the continuations of the line indented smartly.

Functions should not exceed 100 lines (not counting comments). Use your judgement on when to break up long functions into multiple functions.

Indentation

Use tabs to indent. [Rationale: tabs take up fewer bytes in the file. You can configure the size of tabs in your editor, so they can be as big or small as you want without affecting how the file looks on other people's editors.]

Do not use tabs for aligning text; use spaces instead. Alignment will be messed up if someone uses different size tabs than you.

Where to indent

Indent every time a new scope is created, with the exceptions noted in the below section. For example, following a class or function definition, an if statement, etc.

Where not to indent

Do not indent the content of a namespace. Example:

namespace SCOREC {
int i = 1;

if(i < 1) {
  std::cout << "Hello.\n";
}
}

Do not indent the case labels in a switch. Example:

switch (name) {
case 'John':
  x = 2;
  break;	
default:
  x = 3;
  break;
}

Do not indent the public, private, and protected labels in a class. Do not indent preprocessor directives at all, even if they are in a block of code. Preprocessor directives should always be at the beginning of a line, although within a multiline preprocessor directive, indenting is okay.

Conditionals

Put a space between the "if", "while", or "switch" keyword and the condition. Try to avoid putting spaces between the parentheses and the condition.

When comparing a variable with a constant, put the constant on the left of the "==". This will generate a compiler error if you forget an equals sign, making debugging of this problem fairly trivial.

Example:

if (1 == x) {
    // do stuff
} else {
    // do other stuff
}

Curly Braces

For classes and functions, put the opening brace on its own line. Otherwise, put the opening brace on the same line as the previous statement. Put the closing brace at the start of a new line, and follow it with and "else" (for if-else statements) or "while" (for do-while statements) statement on the same line when applicable.

Always use braces for

if, for, while

and the like, even if the content is only one statement. This helps prevent bugs when introducing more statements later on. Case blocks in switch statements do not require braces.

Examples

if statement

if (1 == x) {
    // do stuff
} else {
    // do other stuff
}


switch statement

switch (var) {
case 0:
    // do stuff
    break;
default:
    // do other stuff
}


Class

class foo
{
public:
  foo();
  ~foo();
}

Spaces

Use spaces after keywords, but not functions and not keywords that act like functions. So use a space after these keywords:

if, switch, case, for, do, while

but not:

sizeof, typeof, alignof, or __attribute__.


Do not add spaces around (inside) parenthesized expressions. Example:

Do this:

s = sizeof(struct file);

Don't do this:

s = sizeof( struct file );

When declaring a pointer, put the "*" next to the data name or function name and not next to the type name. Example:

int *i;


Use one space around (on each side of) most binary and ternary operators, such as any of these:

=  +  -  <  >  *  /  %  |  &  ^  <=  >=  ==  !=  ?  :

but no space after unary operators:

&  *  +  -  ~  !  sizeof  typeof  alignof  __attribute__  defined

no space before or after the postfix increment & decrement unary operators:

++  --

and no space around the '.' and "->" structure member operators.

Do not leave trailing whitespace at the ends of lines.

Other

  • Do not put multiple statements on a single line. For instance, don't do the following:
// BAD
if (condition) x = 1;

OR

// BAD
x = 1; y = 2; z = 3;

Pre-processor directives

Conditional Compilation

  • use interfaces whose implementations are determined by the libraries that are linked when building an executable
    •  ??does this make sense to everyone?? --CWS
    • Not sure -- Fabien
    • To be completed
  • Do not use "#ifdef PARALLEL" - serial execution is a degenerate case of parallel execution
Personal tools