4. Naming
-The most important consistency rules are those that govern naming.
-Rules
-Function names, variable names, and filenames should be descriptive;
-Eschew abbreviation.
-Types and variables should be nouns,while functions should be "command" verbs.
-Bad examples
-void count( int[] arr, int value ); // count what ?
-int error_cnt; // error_count ?
-int j,k,l; // always make programs smell bad
-ref. naming.cc
5. Comments
-Comments are absolutely vital to keeping our code readable
-Rules
-Be consistent with //... or /*... */
-File copyright notice, description and author information etc.
-Comment to describe why, how, and what.
-TODO comments
-Bad examples
-mixed // and /* */
-// this is the first function I made.
-ref. comments.cc
6. Formatting
-A project is much easier to follow if everyone uses the same style.
-Rules
-Each line of text in your code should be at most 80 characters long.
-Non-ASCII characters should be rare, and must use UTF-8 formatting.
-Use only spaces, and indent 2 spaces at a time.
-Return type on the same line as function name, parameters on the same line if they fit.
-Prefer no spaces inside parentheses. The else keyword belongs on a new line.
-Switch statements may use braces for blocks. Empty loop bodies should use {} or continue.
-No spaces around period or arrow. Pointer operators do not have trailing spaces.
-Variable or array initialization use = or ( ).
-a preprocessor directive should always be at the beginning of the line.
-Sections in public, protected and private order, each indented one space.
-The contents of namespaces are not indented.
-ref. formatting.cc
7. Head files
-Make a huge difference to the readability, size and performance of code.
-Rules
-one source file for one header file, in general.
-#define guards to prevent multiple inclusion.
-The format of the symbol name should be <PROJECT>_<PATH>_<FILE>_H .
-Don't use an #include when a forward declaration would suffice.
-Define functions inline only when they are small, say, 10 lines or less.
-You may use file names with a -inl.h suffix to define complex inline functions when needed.
-When defining a function, parameter order is: inputs, then outputs.
-Include order: your .h → 3rd lib .h → C lib .h → C++ lib .
-ref. head_files.cc
8. Scoping
-Avoid runtime naming conflicts, save compiling time, etc.
-Rules
-Unnamed namespaces in .cc files are encouraged, Do not use a using-directive.
-Do not declare anything in namespace std even forward declarations of standard library classes.
-Put nested class in a namespace to keep declarations out of the global scope.
-Prefer nonmember or static member functions within a namespace; use global function rarely.
-Place function's variables in the narrowest scope possible, and initialize them in the declaration.
-Static or global variables of class type are forbidden.
-ref. scoping.cc
9. Classes
-Classes are the fundamental unit of code in C++.
-Rules
-constructors set member variables to initial values. Init() method for complex initialization.
-Define a default constructor if you defines member variables and has no other constructors.
-Use the C++ keyword explicit for constructors with one argument.
-Provide a copy constructor and assignment operator only when necessary.
-Use a struct only for passive objects that carry data; everything else is a class.
-Appropriate Composition than inheritance. When using inheritance, make it public.
-Multiple implementation inheritance is a bad idea in most issues.
-Classes satisfy certain conditions are allowed, but not required, to end with an Interface suffix.
-Do not overload operators except in rare, special circumstances.
-Make data members private, and provide access method to them.
- public: before private:, methods before data members (variables), etc.
-Prefer small and focused functions.
- ref. classes.cc
10. Other C++ features
-Details make things boring, details make things shining.
-Rules
-All parameters passed by reference must be labeled const.
-Function overload permitted when same usage different parameters.
-Not allow default function parameters.
-Not allow variable-length arrays or alloca().
-Use of friend classes and functions, within reason.
-Not use C++ exceptions // if you want, think twice.
-Not use Run Time Type Information(RTTI).
-Use C++ casts like static_cast<>(). Do not use cast formats like int y = (int)x; or int y = int(x);
-Use streams only for logging.
-Use prefix form (++i) of the increment and decrement operators.
-strongly recommend to use const.
-Prefer to use int16_t, uint32_t, int64_t in stdint.h
-Be very cautious with macros. Prefer inline functions, enums, and const variables to macros
-Use 0 for integers, 0.0 for reals, NULL for pointers, and '0' for chars.
-se sizeof(varname) instead of sizeof(type) whenever possible.
11. Exceptions to the rules
-Exceptions always should be in control.
-Rules
-Use C++ types not DWORD, HANDLE,etc in your code except you are making Windows API.
-Treat all warnings as errors when you under MS VC++.
-Do not use #pragma once.
-Always have reasons when you think you're facing an exception.
-ref. previous rules.
12. Cpplint
-A tool for checking coding style(Google), in Python.
-Set up Python environment and type:
python cpplint.py your_source_file.cc
-More options, just type:
python cpplint.py
-or read the documentation in the source code.
-ref. cpplint_check.cc
13. Conclusion
Use common sense and BE CONSISTENT.
