编码规范

date:2011.05.24 ~ 2011.06.05

学习c++编码规范，养成良好的代码风格。

Google C++ Style Guide

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Google Objective-C Style Guide

http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml

c++命名规则

http://hi.baidu.com/net629/blog/item/4e8de6321fde034ead4b5fe0.html

1, Header Files

a, All header files should have #define guards to prevent multiple inclusion. The format of the symbol name should be <project>_<path>_<file>_H.

b, Don't use an #include when a forward  declaration would suffice.

c, Define functions inline only when they are small, say, 10 lines or less.

d, You may use file names with a -inl.h suffix to define complex inline functions when needed.

e, When defining a function, parameter order is: inputs, then outputs.

f, Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries' .h, your project's .h

2, Scoping

a, Unnamed namespaces in .cc files are encouraged. With named namespaces, choose the name based on the project, and possibly its path. Don't use a using-direction(eg:using namespace std;).

b, Although you may use public nested classes when they are part of an interface, consider a namespace to keep declarations out of the global scope.

c, Prefer nonmember functions within a namespace or static member functions to global functions: use completely global functions rarely.

d, Place a function's variables in the narrowest scope possible, and initialize variables in the declaration.

e, Static or global variables of class type are forbidden: they cause hard-to-find bugs due to indeterminate order of construction and destruction.

3, Classes

a, In general, constructors should merely set member variables to their intial values. Any complex initialization should go in an explicit Init() method.

b, You must define a default constructor if your class defines member variables and has no other constructors. Otherwise the compiler will do it for you, badly.

c, Use the C++ keyword explicit for constructors with one argument.

d, Provide a copy contructor and assignment operator only when necessary. Otherwise, disable them with DISALLOW_COPY_AND_ASSIGN.

e, Use a struct only for passive objects that carry data;everything else is a class.

f, Interfaces:Classes that satisfy certain conditions are allowed, but not required, to end with Interface suffix.

g, Do not overload operators except in rare, special circumstances.

h, Make data members private, and provide access to them through accessor functions as needed(for technical reasons, we allow data member of a test fixture class to be protected when using Google Test). Typically a variable would be called foo_ and the accessor function foo(). You may also want a mutator function set_foo(). Exception: static const data members (typically called kFoo) need not be private.

i, Use the specified order of declarations within a class: public: before private:, methods before data members(variables), etc.

j, Prefer small and focused functions.

4, Other C++ Features

a, All parameters passed by reference must be labeled const.

b, Use overloaded functions (including constructors) only if reader looking at a call site can get a good idea of what is happening without having to first figure out exactly which overload is being called.

c, We do not allow default function parameters, except in a few uncommon situations explained below.

d, We do not allow variable-length arrays or alloca().

e, We allow use of friend classes and functions, within reason.

f, We do not use C++ exception.

g, We do not use Run Time Type Information (RTTI).

h, Use C++ casts like static_cast<>(). Do not use other cast formats like int y = (int) x; or int y = int (x);.

i, Use streams only for logging.

j, Use prefix form (++i) of the increment and decrement operators with iterators and other template objects.

k, We strongly recommend that you use const whenever it makes sense to do.

l, Of the built-in C++ integer types, the only one used is int. If a program needs a variable of different size, use a precisse-width integer type from <stdint.h>.

m, Code should be 64-bit and 32-bit friendly. Bear in mind problems of printing, comparisons, and structure alignment.

n, Be very cautious with macros. Prefer inline functions , enums, and const variable to macros.

o, Use 0 for integers, 0.0 for reals, NULL for pointers, and '\0' for chars.

p, Use sizeof(varname) instead of sizeof(type) whenever possible.

q, Use only approved libraries from the Boost library collection.

r, Use only approved libraries and language extensions from C++0x. Currently, none are approved.

5, Naming

a, filenames should be all lowercase and include underscores(_) or dashes (-). Follow the convention that your project uses. If there is no consistent local pattern to follow, prefer "_".

b, Type names start with a capital letter and have a capital letter for each new word, with no underscores: MyExcitingClass, MyExcitingEnum.

c, Variable names are all lowercase, with underscores between words. Class member variables have trailing underscores. For instance, my_exciting_local_variable, my_exciting_local_variable_.

d, Use a k followed by mixed case: kDaysInAWeek.

e, Regular functions have mixed case; accessors and mutators match the name of variable:MyExcitingFunction(), MyExcitingMethod(), my_exciting_member_variable(), set_my_exciting_member_variable().

f, Namespace names are all lower_case, and based on project names and possibly their directory structure:google_awesome_project.

g, Enumerators should be named either like constants or like macros: either kEnumName or ENUM_NAME.

h, You're not really going to define a macro, are you? If you do, they're like this: MY_MACRO_THAT_SCARES_SMALL_CHILDREN.

i, If you're naming something that is analogous to an existing C or C++ entity then you can follow the existing naming convention scheme.

6, Comments

a, Use either the // or /**/ syntax, as long as you are consistent.

b, Start each file with a copyright notice, followed by a description of the contents of the file.

c, Every class definition should have an accompanying comment that describes what it is for and how it should be used.

d, Declaration comments describe use of the function; comments at the definition of a function describe operation.

e, In general the actual name of variable should be descriptive enough to give a good idea of what the variable is used for. In certain cases, more comments are required.

f, In your implementation you should have comments in tricky, non-obvious, interesting, or important parts of your code.

g, Pay attention to punctuation, spelling, and grammer; it is easier to read well-written comments than badly written ones.

h, Use TODO comments for code that is temporary, a short-term solution, or good-enough but not perfect.

i, Mark deprecated interface points with DEPRECATED comments.

7, Formatting

a, Each line of text in your code should be at most 80 characters long.

b, Non-ASII characters should be rare, and must use UTF-8 formatting.

c, Use only spaces, and indent 2 spaces at a time.

d, Return type on the same line as function name, parameter on the same line if they fit.

e, Function calls: On one line if it fits; otherwise, wrap arguments at the parenthesis.

f, Conditionals: Prefer no space inside parentheses. The else keyword belongs on a new line.

g, Switch statements may use braces for blocks. Empty loop bodiers should use {} or continue.

h, Pointer and Reference Expressions: No spaces around period and arrow. Pointer operators do not have trailing spaces.

i, When you have a boolean expression that is longer than the standard line length, be consistent in how you break up the lines.

j, Do not needlessly surround the return expression with parentheses.

k, Variable and Array Initialization: your choice of = or ().

l, The hash mark that starts a preprossor directives should always be at the beginning of the line.

m, Class Format: Sections in public, protected and private order, each indented one space.

n, Constructor initializer lists can be all on one line or with subsequent lines indented four spaces.

o, The contents of namespaces are not indented.

p, Horizontal Whitespace: Use of horizontal whitespace depends on location. Never put trailing whitespace at the end of a line.

q, Minimize use of vertical whitespace.