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
Sent: Saturday, May 1, 2021 2:31 AM
To: 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
