C + + code style Guide Summary

The importance of code style in C + + code style guide

Today, I received the news that thougthwork written, I really feel very uncomfortable, and then brother said my code is very bad
Think about it, I write code is really arbitrary, and did not follow any norms; So now determined to repent;

• The first step is to code all by themselves one word a word knock, minimize Ctrl+C and Ctrl+V manipulate
• After you prohibit the use tab of the key to indent, do you have to hit four spaces to die?
• Avoid code verbosity
• Google Open Source project C + + code style guide

Header file

• Header file contains order
  1. The include file for the priority location
  2. C System files
  3. C + + system files
  4. . h files for other libraries
  5. The. h file for this library

Scope

• Use indication (using-directive) is prohibited
• Prohibit the use of inline namespaces (inline namespace)
  • Because the inline namespace puts an internal identifier in the outer scope
  • Inline namespaces are primarily used to maintain cross-version ABI compatibility
• Using anonymous space in a header file results in a violation of the unique definition principle of C + + (one definition rule (ODR)).
• You should not use the using indication to introduce an identity symbol for the entire namespace----pollute the namespace
• Do not declare anything within the namespace STD, including the class predecessor declaration of the Standard library. Declaring an entity in the Std namespace is undefined behavior and can result in non-portability. Declares the entity under the standard library and needs to include the corresponding header file.
• anonymous namespaces and static spaces (internal link properties)
  • When you define a variable in a. cc file that does not need to be externally referenced, you can place them in an anonymous namespace or declared as static ; but do not .h do so in a file
  • All declarations placed in an anonymous namespace have internal linkage, and functions and variables can be declared as static having internal linkage, which means that the identifiers you declare in this file cannot be accessed in another file. Even though two files declare identifiers of exactly the same name, the entities they point to are actually completely different.
• Static member functions, global functions, and non-member functions
  • Put a series of functions directly into the namespace, do not use static methods of the class to simulate the effect of the namespace, the static method of the class should be closely related to the class instance or static data.
• Local variables
  • The function variable is placed as far as possible within the minimum scope and initialized when the variable is declared.
  • It is advocated to declare variables in the smallest possible scope, and the closer the first time is the better.
  • The advantage of this is that reading the code makes it easier to locate the declaration of a variable, understand the initial value and type of the variable, and in particular, use the initialization method instead of the declaration to re-assign the value.
  • Warning: If the variable is an object, each entry to the scope calls its constructor, and each exit scope calls its destructor. This can lead to reduced efficiency.
• Static and global variables
  • Disables the definition of a static storage cycle non-POD variable (native data type (Pod:plain old)) and disables the use of functions with side-effects to initialize the POD global variable, since static variables in a multiple-compilation unit are executed with no explicit construction and destruction order, which causes the code to be non-portable.
  • The constructors and destructors of static variables are only partially defined in C + +, and even change with the construction changes, resulting in difficult to find bugs.
  • Try not to initialize a variable with the return value of the function
  • The same compilation unit is explicit, static initialization takes precedence over dynamic initialization, the initialization sequence is in the order of declaration, and destruction is reversed.
  • The sequence of initialization and destruction between different compilation units belongs to the ambiguous behavior (unspecified behaviour).
  • Global and static variables are destroyed when the program breaks,---the destructor sequence is the opposite of the order in which the constructors are called.
  • Quick_exit () to replace exit () and interrupt the program. Quick_exit does not perform any destructors and does not perform any handlers that atexit () binds to.
  • Allow only static variables of type POD (native data type)
  • Static object, you can consider initializing a pointer within the main () function or pthread_once () and never reclaiming it, only using the raw pointer.
  • Do not use smart pointers, after all, the latter's destructor involves an indefinite order problem
  • Anonymous namespaces This is the file scope, just like the scope of the C static declaration, which has been deprecated by the C + + standard
  • Local variables are explicitly initialized at the same time of declaration, which is more efficient than the two-step process of implicit initialization and re-assignment, and also implements the important concept "locality (locality)" of computer architecture.

Class

• do not call the virtual function in the constructor, nor do the initialization that might fail if the error cannot be reported.
The address of the
• constructor cannot be obtained, so for example, the work done by the constructor cannot be handed over to other threads in a simple way.
• do not define implicit type conversions. For conversion operators and single-argument constructors, use the explicit keyword.
• in the type definition, both the type conversion operator and the single-argument constructor should be marked with explicit. One exception is that copy and move constructors should not be marked as explicit because they do not perform type conversions. Implicit type conversions are sometimes necessary and appropriate for classes designed to be used to transparently wrap other types. This should be done by contacting the project leader and stating the special circumstances.
The
• uses a struct only if it is a data member, and the other uses class.
• in order to be consistent with STL, for features such as functor, you can use structs instead of class.

1. Do not do too much logic-related initialization in the constructor;
2. The default constructor provided by the compiler does not initialize the variable, and if other constructors are defined, the compiler is no longer available and requires the encoder to provide the default constructor itself;
3. To avoid implicit conversions, a single-parameter constructor should be declared as explicit;
4. To avoid copy constructors, the misuse of assignment operations and the compiler's automatic generation can be declared as private and without implementation;
5. Use structs only when you are a collection of data;
6. Combination > Implementation Inheritance > Interface inheritance > Private inheritance, Subclass overloaded virtual functions also declare the virtual keyword, although the compiler allows not to do so;
7. Avoid multiple inheritance, when used, in addition to a base class containing the implementation, the other base classes are pure interface;
8. The class name of the interface class is suffixed with Interface, except for the virtual destructor with the implementation, the static member function, the other is pure virtual function, does not define non-static data member, does not provide the constructor, provides the word, declares as protected;
9. To reduce complexity, try not to overload operators, templates, and standard classes to provide documentation when used;
10. Access functions are generally inline in the header file;
11. Declaration Order: Private, protected, public;
12. function body as short as possible, compact, single function;

Function

• When you arrange the order of the parameters, all input parameters are placed before the output parameters. It is important to note that when adding new parameters, do not place the parameter list at the end of the argument because they are new parameters, but still follow the preceding rules, and the new input parameters will be placed before the output parameters.
• tend to write short, condensed functions.
• You can think about whether it can be segmented without affecting the structure of the program.
• All arguments passed by reference must be given a const.
• Defining reference parameters prevents such ugly code from appearing (*pval) + +. Reference parameters are also required for applications such as copy constructors. It also does not accept null pointers more explicitly.
• A reference is syntactically a value variable but has the semantics of a pointer.
• The input parameter is a value parameter or a const reference, and the output parameter is a pointer. The input parameter can be a const pointer, but must not be a non-const reference parameter, except for special requirements such as Swap ().
• Only default parameters are allowed in non-virtual functions, and the values of the default parameters must always be consistent.
• For virtual functions, default parameters are not allowed because default parameters do not necessarily work correctly in virtual functions.
• The return type post syntax is used only when the general notation (return type pre-set) is not convenient for writing or for readability. ---a post-return type is the only way to explicitly specify the return value of a LAMBDA expression.

The Geek from Google

• Google uses a lot of its own implementation of the skills/tools C + + code more robust
• Ownership and smart pointers: dynamically allocated objects are best to have a single, fixed set of all masters, and pass ownership through smart pointers.
• Smart pointers are * classes that overload the and -> operators to behave like pointers
  • unique_ptrMove ownership to all new master
  • shared_ptrRepresents the ownership of dynamically assigned objects, but can be shared or replicated
• If you don't use shared ownership for good reason, avoid expensive copy operations.
• Do not use auto_ptr , use shared_ptr instead of it.
• Using cpplint.py to check the code style, cpplint.py is a tool for analyzing source files that can check out a variety of style errors.
• Scoped_ptr and auto_ptr are obsolete. Now is the shared_ptr and uniqued_ptr of the world.
• The aur is packed with cpplint.

Other C + + features

• Reference parameters: All arguments passed by reference must be addedconst
  • A reference is syntactically a value variable but has the semantics of a pointer.
  • The input parameter is a value parameter or a const reference, and the output parameter is a pointer. The input parameter can be a const pointer, but must not be a non-const reference parameter unless it is used for swapping.
  • Sometimes, a const t* pointer in an input parameter is more sensible than a const t&.
• Rvalue reference: Use an rvalue reference only when defining a move constructor and a move assignment operation. Do not use Std::forward.
  • An rvalue reference is a type of reference that can only be bound to a temporary object, and its syntax is similar to the traditional reference syntax.
  • The function used to define the move constructor (which is constructed using the class's rvalue reference) makes it possible to move a value rather than a copy.
  • To use certain standard library types efficiently, such as std::unique_ptr, Std::move is required.
• Function overloading: To use a good function overload, it is best to let the reader look at the call site to be confident, without having to speculate on what kind of overloaded functions are called. This rule applies to constructors.
  • The templated code needs to be overloaded while facilitating the user.
• Default parameters: We do not allow the use of default function parameters, except for a few extreme cases. Use function overloading whenever possible.
  • The default parameter interferes with the function signature (functions signature) and often does not sign the function that is actually being called
  • First, static functions or anonymous spatial functions located in a. cc file can only be called in a local file.
  • Second, you can use the default parameters in the constructor, after all, it is impossible to get their addresses.
  • Three, which can be used to simulate variable-length arrays.
• Variable-length arrays and alloca ()
  • We are not allowed to use variable-length arrays and alloca ().
  • Variable-length arrays have a natural syntax. Variable-length arrays and alloca () are also very efficient; But not part of the standard C + + syntax.
  • Switch to a more secure allocator (allocator), just like std::vector or std::unique_ptr<t[]>
• Friend (Friend)
  • We allow a reasonable use of friend and friend functions.
  • Usually friends should be defined within the same file, avoiding the code reader from running to other files to find classes that use that private member.
  • It is convenient to declare a unit test class as a friend of the class to be tested.
  • Friend has expanded (but not broken) the encapsulation boundary of the class. In some cases, it is preferable to declare a class member as public, especially if you only allow another class to access the private members of the class. Of course, most classes should only interoperate through the public members they provide.
• Abnormal
  • We do not use C + + exceptions.
  • Exceptions allow the application executive to decide how to handle "impossible" failures (failures) in the underlying nested functions, regardless of the ambiguous and error-prone code.
  • An exception is the only way to handle a constructor failure.
  • Exceptions can completely disrupt the execution of the program and are difficult to judge, and functions may return where you don't expect them to.
  • For exception handling, obviously not a few short words can be said clearly, with the constructor as an example, many C + + books are mentioned when the construction fails only exception can be handled, Google prohibit the use of exceptions this point, just for their convenience, said Big, is based on software management costs, the actual use or their own Decided
• Runtime type recognition (run time, type information RTTI)
  • RTTI allows programmers to identify types of C + + class objects at run time. It is done by using typeid or dynamic_cast.
  • You can use RTTI in unit tests, but try to avoid them in other code. Especially in the new code, be sure to think twice before using RTTI. If your code needs to perform different behaviors based on different object types, consider querying the type with one of two alternatives.
  • Virtual functions can execute different code depending on the subclass type.
• Type transformation
  • Use a C + + type conversion, such as static_cast<> (). Do not use int y = (int) x or int y = int (x) and other conversions
  • C + + uses a type conversion mechanism different from C to classify the conversion operation.
  • Use static_cast instead of a C-style value conversion, or when a class pointer needs to be explicitly translated upward to the parent class pointer.
  • Remove the const qualifier with Const_cast.
  • Use reinterpret_cast pointer type and integer or other pointers for unsafe mutual conversions. Use only when you are clear about what you are doing.
  • Use Dynatic_cast to convert a derived class pointer to a base class type, or to convert a base class pointer to a derived class pointer.
• Flow
  • The stream is used only when logging is logged.
  • The stream is used instead of printf () and scanf ().
  • With a stream, you don't need to care about the type of object when printing.
  • The construction and destructor of the stream automatically opens and closes the corresponding file.
  • There are a lot of pros and cons to using streams, but code consistency trumps everything. Do not use the stream in your code.
  • Recall the uniqueness principle (only one way): We want to use only a certain type of I/O at any time, so that the code remains consistent across all I/O.
  • The principle of simplicity warns us of the need to choose one, and most of the final decisions are made with printf + read/write.
• Pre-increment or self-decrement
  • For iterators and other template objects, use the prefix form (++i) for the self-increment, decrement operator.
  • If the return value is not considered, the pre-increment (++i) is usually more efficient than the post-increment (i++). Since the post-increment (or decrement) requires a copy of the value of the expression.
  • For simple values (non-objects), neither of them matters. For iterators and template types, use pre-increment (self-decrement).
• Const usage
  • We strongly recommend that you use the const in any possible situation. In addition, sometimes it is better to switch to C++11 to launch the constexpr.
  • Precede the declared variable or parameter with the keyword const to indicate that the value of the variable cannot be tampered with (such as const int foo). Adding a const qualifier to a function in a class indicates that the function does not modify the state of a class member variable
  • It's easier for everyone to understand how to use variables. The compiler is better at type detection and, as a result, better code can be generated.
  • If the function does not modify the reference or pointer type argument that passes you in, the parameter should be declared as Const.
  • Declare the function as const whenever possible. The Access function should always be const. The other does not modify any data member, does not call a non-const function, does not return a data member, a non-const pointer, or a referenced function should also be declared as Const.
  • If a data member does not change after the object is constructed, it can be defined as const.
  • The keyword mutable can be used, but it is unsafe in multi-threading, with the first consideration of thread safety.
  • Keep the code consistent: that is, do not write the const in some places in front of the type, write it back in other places, define a style, and then keep it consistent.
• CONSTEXPR usage
  • In c++11, use constexpr to define a true constant, or to implement a constant initialization.
  • A variable can be declared as constexpr to indicate that it is a true constant, that is, both at compile time and at run time. Functions or constructors can also be declared as constexpr to define CONSTEXPR variables
  • By the constexpr feature, it is possible to create a true constant mechanism on the interface of C + +. Use constexpr to define true constants and functions that support constants. Avoid complex function definitions so that they can be used with constexpr. Don't try to rely on constexpr to force code "inline
  • constexpr keyword Explanation
  • CONSTEXPR Compile-time constants
• Integer
  • In C + + built-in integers, use only int. If you need variables of different sizes in your program, you can use the exact length of an integer in <stdint.h>, such as int16_t. If your variable may not be less than 2^31 (2GiB), use a 64-bit variable such as int64_t . Also note that even if your value does not exceed the range that int can represent, it may overflow during the calculation process. So when in doubt, simply use a larger type
  • C + + does not specify the size of an integral type. It is usually assumed that short is 16 bits, int is 32 bits, long is 32 bits, and long long is 64 bits.
  • The size of an integer in C + + differs depending on the compiler and architecture.
  • You should use assertions to protect your data.
  • Use assertions to indicate that a variable is non-negative, instead of using an unsigned type
• Portability under 64-bit
  • The code should be friendly to both 64-bit and 32-bit systems. Handle printing, comparison, structure alignment should remember
  • Persistence-saves data in a byte-stream file or database.
  • Use __attribute__((packed)) to align structure in gcc
• Preprocessing macros
  • Be very cautious when using macros, as far as possible inline functions, enumerations and constants instead.
  • Macros mean that the code you see with the compiler is different. This can cause unexpected behavior, especially because macros have global scope.
  • The usage patterns given below can avoid the problem of using macros; If you want macros, follow as much as possible:
    • Do not define macros in the. h file.
    • #define should be used immediately and #undef immediately after use.
    • Do not just use #undef for existing macros, choose a name that does not conflict;
    • Do not try to use a macro that causes C + + construction to be unstable after you expand it, or at least attach a document stating its behavior.
    • Do not use # # to handle functions, classes, and names of variables
• 0, NULL and nullptr
  • Integers with 0, real numbers with 0.0, pointers with nullptr or NULL, characters (strings) with ' + '.
  • For pointers (address values), exactly 0, NULL, or nullptr. C++11 project with nullptr; The C++03 project is null, after all, it looks like a pointer. In fact, some C + + compilers have a special definition of NULL, which can output useful warnings, especially if sizeof (NULL) is not the same as sizeof (0).
  • Characters (strings) are not only correct in type but also good in readability.
• sizeof
  • Use sizeof (varname) instead of sizeof (type) whenever possible.
• Auto
  • Use Auto to bypass cumbersome type names, as long as readability is good, continue to use, do not use outside the local variables
  • In c++11, if a variable is declared as auto, its type is automatically matched to the type of the initialization expression
  • Code to avoid the repetition of no matter
  • Auto can only be used in local variables. Do not use in file-scoped variables, namespace-scoped variables, and class data members. Never list initialize auto variable
  • Auto can also be used with the c++11 feature "tail return type (Trailing return"), although the latter can only be used in lambda expressions
• Initialize List
  • C++11, this feature is further promoted, and any object type can be initialized by the list.
  • A user-defined type can also define a receive std::initializer_list
  • List initialization also applies to the construction of regular data types, even if no std::initializer_list is received
• Lambda expression
  • Use lambda expressions appropriately. Do not use the default lambda capture, all captures are explicitly written out
  • Lambda expressions are an easy way to create anonymous function objects, often used to pass functions as arguments
  • Lambdas, Std::functions and Std::bind can be paired with a generic callback mechanism (general purpose callback mechanism); it's easy to write a function that takes a parameter of a bounded function.
  • Small lambda expression by format.
  • Disables the default capture, and captures are explicitly written out. For example, rather than = {return x + N;}, you should write n {return x + N;}, so the reader is good at seeing that N is the value captured.
  • Anonymous functions are always short, if the function body exceeds the five elements, then it is better to name (Acgtyrant Note: The lambda expression is assigned to the object), or use a function instead.
  • If readability is better, the LAMBD return type is explicitly written out, just like auto.
• Template programming
  • Do not use complex template programming
  • Template programming refers to the use of C + + template instantiation mechanism is Turing completeness, can be used to achieve compile time type judgment of a series of programming skills
  • Advantages and disadvantages of template programming
• Boost Library
  • Use only libraries that are recognized in Boost.
• C++11
  • Appropriately use C++11 (formerly c++0x) libraries and language extensions to think twice about portability before your project uses C++11 features

Naming conventions

• The most important consistency rule is naming management.
• types, variables, functions, constants, macros, and so on, even. The pattern matching engine in our brains relies heavily on these naming conventions.
• The consistency of the naming conventions is more important, so whether you think they are important or not, the rules are rules.
• Universal Naming conventions
  • function naming, variable naming, file naming should be descriptive; Use fewer abbreviations.
  • Use descriptive naming whenever possible, and do not love the space, after all, it is more important to make the code easier for new readers to understand. Don't use abbreviations that only project developers can understand, and don't abbreviate words by cutting down a few letters.
• File naming
  • File names are all lowercase and can contain underscores () or hyphens (-), according to the contract of the project. If there is no agreement, then "" better.
• Type naming
  • The first letter of each word of the type name is capitalized and does not contain underscores: Myexcitingclass, Myexcitingenum.
  • All type naming-classes, structs, type definitions (typedef), enumerations, type template parameters-all use the same convention, starting with uppercase letters, with the first letter of each word capitalized and without underscores.
• Variable naming
  • Variables (including function parameters) and data member names are all lowercase, and the words are concatenated with underscores.
  • The member variable of the class ends with an underscore, but the struct is not used, such as: A_local_variable, A_struct_data_member, A_class_data_member_.
  • Normal variable lowercase
  • Whether static or non-static, struct data members can be the same as normal variables without being underlined like a class
• Constant naming
  • Variables that are declared as constexpr or const, or whose values always remain constant during a program's run, are named with a "K" and mixed case.
• function naming
  • Regular functions use case blending, and values and SetPoint functions require matching with variable names
  • In general, the first letter of each word of the function name is capitalized (that is, "Hump variable name" or "Pascal variable name"), without underlining. For acronyms, they are more likely to be capitalized as a single word (for example, writing STARTRPC () rather than STARTRPC ()).
• namespace naming
  • Namespaces are named in lowercase letters.
  • The name of the highest-level namespace depends on the project name.
  • Be aware that there is a conflict between the names of nested namespaces and the names of common top-level namespaces.
  • Note rules that do not use abbreviations as names also apply to namespaces. There is very little code in the namespace that involves the name of the namespace, so it is not necessary to use abbreviations in the namespace.
• Enumeration naming
  • The name of the enumeration should be consistent with constants or macros: Kenumname or Enum_name.
  • Individual enumeration values should take precedence over the naming of constants. But the name of the macro method is also acceptable.
• Macro naming
  • The name of the macro is named like this: My_macro_that_scares_small_children.
  • Macros should not normally be used. If it has to be used, its name is all capitalized as the enumeration name, using underscores
• Feel Google's naming convention is very clever, such as writing a simple class queryresult, and then can directly define a variable Query_result, the degree of distinction is very good; Once again, the variable in the class ends with an underscore, so you can pass in a formal parameter with the same name, such as Textquery::textquery (std::string word): Word_ (Word) {}, where Word_ is naturally a private member within the class.

Comments

• Notes are painful to write, but are critical to ensuring code readability.
• While annotations are important, the best code should be the document itself. Meaningful type names and variable names are far better than ambiguous names to be interpreted with annotations.
• Annotation style
  • Use // or /* ···*/ , the uniform style is good.
• File Comments:
  • A copyright notice is added at the beginning of each file, and a file comment describes the contents of the file. If a file only declares, or implements, or tests an object, and the object has been commented in detail at its declaration, then there is no need to add a file comment. Other documents require a file comment.
  • Do not copy comments between. h and. CC, such comments deviate from the actual meaning of the comment.
• Class Comments:
  • Each class definition is accompanied by a comment that describes the function and usage of the class, unless its functionality is quite obvious.
  • Annotations that describe the usage of a class should be put together with the interface definition, and comments describing the operation and implementation of the class should be put together with the implementation.
• Function Comment:
  • Description function function at function declaration; The annotation at the definition describes the function implementation.
  • Basically, each function declaration should be preceded by a comment, describing the function and purpose. These annotations can be omitted only if the function is simple and obvious (for example, a simple value and a set-valued function).
• Make the code self-documenting.
• Pay attention to punctuation, spelling and grammar; A good note is much easier to read than a poor writer.
• TODO comment style
• With regard to the annotation style, many C + + coders prefer the line comment, C coders may still love the block comment, or use block annotation when the large paragraph of the file header is commented;
• File comments can show off your accomplishments, but also to poke a basket of people can find you;
• Note to be concise, do not procrastinate redundant, complex things simplification and simple things complicated are to be despised;
• For Chinese coders, it is a problem to comment in English or in Chinese, but anyway, is it for the sake of others to show off your native or foreign language level outside of the programming language?
• Note don't be too messy, proper indentation will make people happy to see. But there is no need to stipulate that the comments start from the first column (I always like this when I write code), Unix/linux can also be agreed to use tab or space, individuals tend to space;
• TODO is good, sometimes the annotations are really to mark some unfinished or unfinished place, so a search will know what else to do and the logs will be saved.

Format

• Everyone may have their own code style and format, but if everyone in a project follows the same style, the project will work more smoothly. Everyone may not be able to agree to each of the following formatting rules, and many of these rules require a certain amount of time to adapt, but it is important that the entire project be subject to a unified programming style, so that everyone can easily read and understand the code.
• Line length:
  • Maximum of 80 characters per line
• Try not to use non-ASCII characters, you must use UTF-8 encoding when using.
• We use spaces to indent. Do not use tabs in your code. You should set the editor to convert tabs to spaces.
• Use a good parameter name.
• Parameter names can be omitted only if they are not in use or are used very clearly.
• If the return type and function name do not fit on one line, branch.
• If the return type is in line with the function declaration or definition, do not indent.
• The left parenthesis is always the same line as the function name.
• There is never a space between the function name and the left parenthesis.
• There is no space between the parentheses and the parameter.
• The opening brace always ends at the end of the same line as the last parameter, and does not start a new row.
• The closing brace is always on the last line of the function alone, or on the same line as the opening curly brace.
• There is always a space between the right parenthesis and the left curly brace.
• All formal parameters should be aligned as much as possible.
• The default indentation is 2 spaces.
• The argument after the line break keeps the indentation of 4 spaces.
• The use of horizontal white is determined by the position in the code. Never add meaningless white leaves at the end of a line.

C + + code style Guide Summary