Hi everyone, Thanks, Jacob, for putting together a list of differences with the Google Style Guide for C++! I just wanted to mention 2 things:
1. Member variables names as of Google style guide requires a '_' char to be added at the end so it can be identified. Should we also adopt that? For example, imagine you have a region mutex, so, should we name it as 'regionMutex_' ? 2. Also, I would like to point out that macros are dis-recommended but every C++ committee member I know. What do you think about adding a notice saying: "Macros should be avoided and only used when there is no alternative"? Thanks, Mario. ________________________________ From: Jacob Barrett <jabarr...@vmware.com> Sent: Saturday, May 1, 2021 2:31 AM To: dev@geode.apache.org <dev@geode.apache.org> Subject: DISCUSSION: Geode Native C++ Style and Formatting Guide Team, We haven’t been good about documenting our style and formatting guidance. Like the Java sources are loosely styled after the Google Java Style Guide, the C++ sources are loosely styled after the Google C++ Style Guide. We deviate in some places from the Google C++ Style Guide. Without these documented it can be confusing to new or even infrequent committers. I would like us to discuss and then document our consensus in the CONTRIBUTING.md. If you look at https://github.com/apache/geode-native/blob/develop/CONTRIBUTING.md#style you will notice there are no deviations documented. To my recollection we have these deviations as common practice: https://google.github.io/styleguide/cppguide.html#C++_Version C++ Version Currently, code should target C++11. [ Google: Currently, code should target C++17. ] https://google.github.io/styleguide/cppguide.html#Forward_Declarations Forward Declarations Forward declarations are allowed to reduce build time. Solving for complex includes should be preferred over this. See include what you use. [ Google: Don’t use forward declarations ] https://google.github.io/styleguide/cppguide.html#cpplint cpplint [Add] Prefer using clang-tidy and clang-format with the provide configuration files to validate style and format. https://google.github.io/styleguide/cppguide.html#Exceptions Exceptions We use C++ exceptions. [ Google: We do not use C++ exceptions. ] https://google.github.io/styleguide/cppguide.html#Boost Boost Use only libraries from the Boost library collection when an alternative is not available in the standard library. [ Google: Use only approved libraries from the Boost library collection. ] https://google.github.io/styleguide/cppguide.html#File_Names FIle Names File names should match the case of the class declared within. C++ files should end in .cpp and their corresponding header should end with .hpp. Header only files may use .h extension. https://google.github.io/styleguide/cppguide.html#Variable_Names Variable Names: Common Variable Names: Use camelCase variable names. [ Google: Use _ separated variable names. ] https://google.github.io/styleguide/cppguide.html#Function_Names Function Names: Regular functions have camelCase; accessors and mutators may be named like variables. [ Google: Regular functions have mixed case; accessors and mutators may be named like variables. ] https://google.github.io/styleguide/cppguide.html#Macro_Names Macro Names: Prefix all macros with ‘GEODE' [ Google: No prefix requirement ] https://google.github.io/styleguide/cppguide.html#File_Comments Legal Notice and Author Line Every file should start with the Apache 2.0 license notice. [ Google: Every file should contain license boilerplate. Choose the appropriate boilerplate for the license used by the project (for example, Apache 2.0, BSD, LGPL, GPL).] No author name(s) should be used in the source. [ Google: If you make significant changes to a file with an author line, consider deleting the author line. New files should usually not contain copyright notice or author line. ] https://google.github.io/styleguide/cppguide.html#Class_Comments Class Comments [Add] Use Doxygen style comment format. https://google.github.io/styleguide/cppguide.html#Function_Comments Function Declarations [Add] Use Doxygen style comment format. https://google.github.io/styleguide/cppguide.html#Variable_Comments [Add] Use Doxygen style comment format. https://google.github.io/styleguide/cppguide.html#TODO_Comments TODO Comments TODOs should include the string TODO in all caps. TODOs should not contain any personal identifying information or bug ID. [ Google: TODOs should include the string TODO in all caps, followed by the name, e-mail address, bug ID, or other identifier of the person or issue with the best context about the problem referenced by the TODO ] These we should adopt but haven’t out of respect of previous convention: https://google.github.io/styleguide/cppguide.html#Enumerator_Names Enumerator Names: Using Googles prescribed naming convention avoids collisions with leaky macros. I am indifferent to the use of the ‘k’ prefix but since they are constants it does make it consistent. We currently have a mix of camelCase and UPPERCASE enum constants. Proposed changes we should adopt: https://google.github.io/styleguide/cppguide.html#Line_Length Line Length Each line of text in your code should be at most 100 characters long. Pro: Consistent with Geode Java Guide. [ Google: Each line of text in your code should be at most 80 characters long. ] Please comment or add anything I might have missed so we can get these recorded. Thanks, Jake
