Google releases C ++ code style specifications

Recently, Google released C ++CodeStyle specifications can be found here: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml.

This is a detailed C ++ development code style specification. Like many other companies, this specification specifies a large number of questions about what to do and what not to do, excerpt from several interesting aspects:

1. Try to avoid writing exceptions as much as possible. I am afraid this is intolerable for many people who have learned modern languages, especially from Java, this is not acceptable to anyone who writes abnormal security code in C ++. The above rules also carefully refer to those who agree with or disagree with each other. As c ++ is generated due to its historical reasons, C-compatible code and similar style, many third-party libraries using C ++ may not always use exceptions, this causes the exception check to become very troublesome. Google considers more reasons for third-party compatibility and requires that you avoid writing exceptions in the Code as much as possible.

2. When using rtti, exceptions have been removed as much as possible, so rtti will naturally be disabled.

3. It is very interesting to name the implementation file. It is not a common CPP. What are the benefits !?

4. inline functions are placed in-inL. H, which is clearer than in the. h file. The file name can be used to distinguish whether it is a common header file or an inline function file.

5. Google provides a python tool to check for compliance with this specification.ProgramFile cpplint. py. Google still enjoys the python style.

6. Avoid Hungary naming, which may be difficult for those who develop MFC programs on Windows platforms to accept.

7. The description of the lpctstr is better than that of the implied description. Therefore, we recommend that you use const tchar * as much as possible to define it.

8. For parameter reference, the requirement must be of the const type. This is necessary. Although the reference can also transmit values, it cannot be clearly seen from the beginning of the Code.

References may return values, which may also lead to inconsistent style specifications in the Code. The pointer is used to indicate the outgoing value, which is more obvious. If the two are combined, it is easy to understand what kind of parameters are passed in, and what kind of parameters may have outgoing values.

Other standards are similar or identical in naming or code style standards issued by other companies.

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

Of course, Google's stuff is not all OK. It is good or wrong. The key is to have a stable code style.