Google C + + style guide--format

1. Line length
The number of code characters per line does not exceed 80.
Exception:
1) Assume that a line of gaze includes more than 80 characters of the command or URL, for the convenience of copying and pasting more than 80 characters;
2) including the long path can exceed 80 columns, try to avoid;
3) header File Protection can ignore this principle


2. Non-ASCII characters
Try not to use non-ASCII characters, you must use the UTF-8 format when using.
Try not to couple string constants into your code. For example, separate out the resource file.

3. Spaces or Tab stops
Use only spaces to indent 2 spaces at a time.
Use a space to indent, do not use tab in your code, and set the editor to turn the tab into a space.


4. function declaration and definition
The return type and function name are on the same line, and if appropriate, the parameters are also on the same line.
Notice the points:
1) The return value is always on the same line as the function name.
2) The left parenthesis is always the same line as the function name;
3) There is no space between the function name and the left parenthesis;
4) There is no space between the parentheses and the parameters;
5) The left curly brace is always at the end of the last number of the same line.
6) The closing curly brace is always on the last line of the function alone.
7) There is always a space between the right parenthesis and the left curly brace.
8) The function declaration and implementation of the full name must be consistent;
9) All the shapes should be aligned as far as possible.
10) The default indentation is 2 spaces;
11) The independent package of the number of parameters to maintain the indentation of 4 spaces.

Assuming that the function is const, the keywordconst should be on the same line as the last parameter.

Assuming that some of the parameters are not practical, the function defines the name of the reference to gaze at.

5. Function calls
Put it on the same line as possible, or enclose the actual participation in parentheses:
BOOL retval = dosomething (ARGUMENGT1,ARGUMENT2,ARGUMENT3);
Let's say the same line doesn't fit. Can be broken into multiple lines, and each subsequent line is aligned with the first one. Left parenthesis and right parenthesis do not leave spaces before:
BOOL retval = dosomething (AVERYVERYVERYLONGARGUMENT1,ARGUMENT2,ARGUMENT3);
Assuming that the function has a larger number of parameters, it is possible to be readable by taking only one parameter per line:
BOOL retval = dosomething (argument1,
Argument2,
Argument3,
ARGUMENT4);
Assume that the function name is too long. So that it exceeds the maximum length of the line. The ability to separate all of the parameters:
if (...) {
...
...
if (...) {
Dosomethingthatrequiresalongfunctionname (
Very_long_argument1,
Argument2,
Argument3,
ARGUMENT4);
}
}


6. Conditional statements
More advocates not to add a space in parentheses, keywordelse another line.
There are two acceptable formats for basic conditional statements. There is a space between the parentheses and the condition, one without.
Choose which one. Consistency is still the main.
Note that in all cases, there is a space between the IF and the left parenthesis. There should also be a space between the right parenthesis and the left brace.

if (condition)//Bad-space missing after if.
if (condition) {//Bad-space missing before {.
if (condition) {//doubly bad.
if (condition) {//Good-proper space after IF and before {
In general, one-line statements do not need braces, and it is understandable if you like, or if you must use braces.
But assuming that the branch in the statement uses curly braces, the rest must also be used:
Not allowed-curly on IF and not ELSE
if (condition) {
Foo
} else
Bar
Not allowed-curly on ELSE and not IF
if (condition)
Foo
else {
Bar
}
Curly braces around both IF and ELSE required because
One of the clauses used braces.
if (condition) {
Foo
} else {
Bar
}


7. Loop and switch selection statements
The switch statement is capable of using curly braces to block. The empty loop body should use {} or continue.

The case block in a switch statement can also be used without a brace, depending on your preference, as described below.
Suppose there is a value that does not satisfy the case enumeration condition. To always include a default (assuming that there is no case to handle the input value, the compiler will
Alarm).

Assuming that default never runs, you can simply use assert:
Switch (VAR) {
Case 0: {//2 space indent
...//4 space indent
Break
}
Case 1: {
...
Break
}
Default: {
ASSERT (FALSE);
}
}
The empty loop body should use the {} ring continue instead of a simple semicolon:
while (condition) {
Repeat test until it returns false.
}
for (int i = 0; i < Ksomenumber; ++i) {}//Good-empty body.
while (condition) continue; Good-continue indicates no logic.
while (condition); Bad-looks like part of Do/while loop.


8. Pointers and Reference expressions
Do not have a space before or after a period (.) or an arrow (--), and do not have a space after the pointer/address operator (*,&).
When you declare a pointer variable or argument, the asterisk and the type or variable name are close to each other:
These is fine, space preceding.
Char *c;
Const string &str;
These is fine, space following.
char* C; But remember to do "char* C, *d, *e, ...;"!
Const string& STR;
char * C; Bad-spaces on both sides of *
const string & str; Bad-spaces on both sides of &
At a minimum, the same file (new or existing) should remain consistent.




9. Boolean expressions
Suppose a Boolean expression exceeds the standard line width (80 characters). Suppose you want to unify the break.
if (this_one_thing > This_other_thing &&
a_third_thing = = A_fourth_thing &&
Yet_another & Last_one) {
...
}


10. function return value
Do not use parentheses in the return expression.
Do not use parentheses when returning functions.


11. Initialization of variables and arrays.
select = or ().


12. Pre-processing instructions
Preprocessing directives do not indent. Start at the beginning of the line.
Even if the preprocessing directives are in the indent code block. Instructions should also start at the beginning of the line.
Good-directives at beginning
if (Lopsided_score) {
#if disaster_pending//Correct--starts at beginning
Dropeverything ();
#endif
Backtonormal ();
}
bad-indented directives
if (Lopsided_score) {
#if disaster_pending//wrong! The "#if" should is at beginning's line
Dropeverything ();
#endif//wrong! Do not indent "#endif"
Backtonormal ();
}


13. Class Format
The Declaration property order is public, protected, private. Indents one space at a time.
Except for the first keyword. Other keywords in front of the empty line, if the analogy is smaller, can not be empty.


14. Initialize the list
The constructor initialization list is placed in the same row or indented in a few rows by four cells.

Two acceptable initialization list formats:
When it all fits on one line:
Myclass::myclass (int var): Some_var_ (Var), Some_other_var_ (var + 1) {
Or
When it requires multiple lines, indent 4 spaces, putting the colon on
The first initializer line:
Myclass::myclass (int var)
: Some_var_ (Var),//4 space indent
Some_other_var_ (var + 1) {//lined up
...
DoSomething ();
...
}


15. Namespace formatting
Namespace content is not indented.
Namespaces do not include additional indentation levels, such as:
namespace {


void Foo () {//Correct. No extra indentation within namespace.
...
}


}//Namespace
Do not indent:
namespace {


Wrong. Indented when it should isn't be.
void Foo () {
...
}


}//Namespace


16. Horizontal Blank
Horizontal blank use of local conditions.

Do not add unnecessary blanks at the end of the line.

17. Vertical Blanks
The fewer vertical blanks the better.
Do not empty more than 2 rows between the two function definitions, and do not have blank lines on the body head and tail of a function. Do not add any blank lines to the function body.

Google C + + style guide--format