[GitHub] [nifi-minifi-cpp] lordgamez commented on a change in pull request #1146: MINIFICPP-1617 Update CONTRIB.md with current practice

[GitBox <gi...@apache.org>]

lordgamez commented on a change in pull request #1146:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1146#discussion_r679167560



##########
File path: CONTRIB.md
##########
@@ -15,24 +15,59 @@
 
 # Apache NiFi - MiNiFi - C++ Contribution Guide
 
-
-We welcome all contributions to Apache MiNiFi. To make development easier, we've included
-the linter for the Google Style guide. Google provides an Eclipse formatter for their style
-guide. It is located [here](https://github.com/google/styleguide/blob/gh-pages/eclipse-cpp-google-style.xml).
-New contributions are expected to follow the Google style guide when it is reasonable.
-Additionally, all new files must include a copy of the Apache License Header.
-
+We welcome all contributions to Apache MiNiFi. All new files must include a copy of the Apache License Header.
+To make development easier, we've included the linter for the Google Style guide. Google provides an Eclipse formatter
+for their style guide. It is located
+[here](https://github.com/google/styleguide/blob/gh-pages/eclipse-cpp-google-style.xml).
+New contributions are expected to follow the Google Style Guide, except for the following points:
+- Use .cpp extension for implementation files
+- Use lowerCamelCase for functions, including accessors/mutators
+- Use UPPER_SNAKE_CASE for constants
+- Filenames are typically class names or a description of the contents in UpperCamelCase
+- If a class is imitating something from STL, boost or similar, then STL-style lower_snake_case is used for naming the
+  class. UpperSnakeCase is used for most classes, in line with the Google Style Guide.
+- Prefer `#pragma once` over include guards
+- Forward declarations are OK
+- Using-directives (`using namespace foo`) are discouraged, except for user-defined literal namespaces
+- Some patterns in the codebase rely on objects with static storage duration without being trivially destructible and
+  initialized with a constant expression. It's OK to use these.
+- Operator overloading and user-defined literal suffixes are OK

Review comment:
       I'm not a fan of operator overloading, but it is because of my own bad experiences. But I think my own bad experiences shouldn't discourage anyone who would create an excellent interface through operator overloading. I wouldn't add the `but use them sparingly` part, and I would rather say `but only use them if they do not make the code less readable`. In that case if we catch a similar problem on review we can point to this part of the CONTRIB.md.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@nifi.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org