-
Notifications
You must be signed in to change notification settings - Fork 6
Coding Style Guide
Based on https://bitbucket.org/verateam/vera/wiki/Rules
As a commonly accepted practice, line breaks are denoted by a single '\n' (LF) character or by two characters "\r\n" (CRLF). A single appearance of '\r' (CR) is discouraged.
Automatically with Linux and Mac, on Windows: Git corrects this on commit
The source file names should be well-formed in the sense of their allowed maximum length and directory depth. Directory and file names should start with alphabetic character or underscore. In addition, directory names should not contain dots and file names can have only one dot.
Name Default Description
----------------------- --------- -------------------------------------------------
max-directory-depth 8 Maximum depth of the directory structure.
max-dirname-length 31 Maximum length of the directory path component.
max-filename-length 31 Maximum length of the leaf file name.
max-path-length 100 Maximum length of the full path.
Trailing whitespace is any whitespace character (space or tab) that is placed at the end of the source line, after other characters or alone.
The presence of trailing whitespace artificially influences some source code metrics and is therefore discouraged.
As a special case, the trailing whitespace in the otherwise empty lines
is allowed provided that the amount of whitespace is identical to the
indent in the previous line - this exception is more friendly with less
smart editors, but can be switched off by setting non-zero value for the
strict-trailing-space parameter.
Horizontal tabs are not consistently handled by editors and tools. Avoiding them ensures that the intended formatting of the code is preserved.
pass
Leading and trailing empty lines confuse users of various tools (like
head and tail) and artificially
influence some source code metrics.
The source code line should not exceed 120 characters.
The empty lines (if any) help to introduce more "light" in the source code, but they should not be overdosed in the sense that too many consecutive empty lines make the code harder to follow.
Lines containing only whitespace are considered to be empty in this context.
Name Default Description
------------------------------- --------- --------------------------------------------
max-consecutive-empty-lines 2 Maximum number of consecutive empty lines.
The source file should not exceed 2000 lines.
Long source files can indicate an opportunity for refactoring.
The one-line comment is a comment that starts with //.
The usual intent is to let the comment continue till the end of the line, but the preprocessing rules of the language allow to actually continue the comment in the next line if line-splicing is forced with the backslash at the end of the line:
void foo()
{
// this comment is continued in the next line \
exit(0);
}
It is not immediately obvious what happens in this example. Moreover, the line-splicing works only if the backslash is really the last character in the line - which is error prone because any white characters that might appear after the backslash will change the meaning of the program without being visible in the code.
Keywords from the following list:
caseclassdeletedelete[]enumexplicitexterngotonewstructunionusing
should be followed by a single space for better readability.
Keywords from the following list:
defaultprivateprotectedpublic
should be immediately followed by a colon, unless used in the list of base classes:
class A : public B, private C
{
public:
A();
~A();
protected:
// ...
private:
// ...
};
void fun(int a)
{
switch (a)
{
// ...
default:
exit(0);
}
}
The return and throw keywords should be
immediately followed by a semicolon or a single space:
void fun()
{
if (...)
{
return;
}
// ...
}
int add(int a, int b)
{
return a + b;
}
An exception to this rule is allowed for exeption specifications:
void fun() throw();
The semicolon should not stand isolated by whitespace or comments from the rest of the code.
int a ; // bad
int b
; // bad
int c; // OK
As an exception from this rule, semicolons surrounded by spaces are
allowed in for loops:
for ( ; ; ) // OK as an exception
{
// ...
}
Keywords catch, for, if,
switch and while should be followed by a
single space and then an opening left parenthesis:
catch (...)
{
for (int i = 0; i != 10; ++i)
{
if (foo(i))
{
while (getline(cin, line))
{
switch (i % 3)
{
case 0:
bar(line);
break;
// ...
}
}
}
}
}
A comma, whether used as operator or in various lists, should not be preceded by whitespace on its left side, but should be followed by whitespace on its right side:
void fun(int x, int y, int z);
int a[] = {5, 6, 7};
class A : public B,
public C
{
// ...
};
An exception to this rule is allowed for operator,:
struct A {};
void operator,(const A &left, const A &right);
An exception to this rule is allowed for initialisation in inline constructors:
A(B b, C c)
: b(b)
, c(c)
Corresponding curly brackets should be either in the same line or in the same column. This promotes clarity by emphasising scopes, but allows concise style of one-line definitions and empty blocks:
class MyException {};
struct MyPair
{
int a;
int b;
};
enum state { close, open };
enum colors
{
black,
red,
green,
blue,
white
};
Control structures managed by for, if and while constructs can be associated with a single instruction or with a complex block of code. Standardizing on the curly-braced blocks in all cases allows one to avoid common pitfalls and makes the code visually more uniform.
if (x) foo(); // bad style
if (x) { foo(); } // bad style
if (x)
{
foo();
} // OK
if (x)
foo(); // again bad style
if (x)
{ // OK
foo();
}
if (x)
while (y) // bad style
foo(); // bad style
if (x)
{ // OK
while (y)
{ // OK
foo();
}
}
for (int i = 0; i = 10; ++i); // oops!
cout << "Hello\n";
for (int i = 0; i = 10; ++i) // OK
{
cout << "Hello\n";
}