fgerlits commented on a change in pull request #1146: URL: https://github.com/apache/nifi-minifi-cpp/pull/1146#discussion_r679024480
########## 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. Review comment: typo: ```suggestion class. UpperCamelCase is used for most classes, in line with the Google Style Guide. ``` ########## 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 +- Public mutable data members are allowed +- Inline function definition is OK +- Rvalue references, exceptions and RTTI are allowed +- Use gsl::narrow and gsl::narrow_cast in addition to standard casts. The codebase doesn't use abseil. +- We are more liberal regarding the use of `auto`. The Google Style Guide only allows using it when it makes the code + clearer. In MiNiFi C++, it's up to the personal preferences of the contributor. +- Template metaprogramming is OK as long as the usage is clear. Review comment: Suggested addition: ```suggestion - Template metaprogramming is OK where it is necessary, as long as the usage is clear. Prefer `if constexpr` to `std::enable_if`. ``` ########## 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 +- Public mutable data members are allowed +- Inline function definition is OK +- Rvalue references, exceptions and RTTI are allowed +- Use gsl::narrow and gsl::narrow_cast in addition to standard casts. The codebase doesn't use abseil. +- We are more liberal regarding the use of `auto`. The Google Style Guide only allows using it when it makes the code + clearer. In MiNiFi C++, it's up to the personal preferences of the contributor. +- Template metaprogramming is OK as long as the usage is clear. +- Static data members are capitalized according to lower_snake_case, in contrast to the Google Style Guide, which uses Review comment: I think our current usage of static (non-constant) data members is mixed, both with trailing `_` and without. I would prefer having the trailing `_` in new code, as I would rather distinguish static members from local variables than from non-static members. ########## 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: Suggested addition: ```suggestion - Operator overloading and user-defined literal suffixes are OK, but use them sparingly and only where they make the code more readable ``` -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
