fgerlits commented on a change in pull request #1146: URL: https://github.com/apache/nifi-minifi-cpp/pull/1146#discussion_r679946074
########## File path: CONTRIB.md ########## @@ -15,24 +15,70 @@ # 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 C++ Style Guide](https://google.github.io/styleguide/cppguide.html), 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. UpperCamelCase 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. +- 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 when necessary, as long as the usage is clear. Prefer the more readable alternatives + when applicable. +- Enums are either UPPER_SNAKE_CASE or UpperCamelCase. +- File-level comments describing the contents are not required and typically not used in the codebase. A license header + is required. +- Function comments use /** Javadoc style */ +- Line length is not limited, but the linter warns on lines longer than 200 characters. Use a NOLINT line comment in the + rare case when a longer line is more readable than splitting it up. +- Continuation indentation is ok with either 2 levels of indentation (4 spaces) or aligned. + +It's ok to diverge from any of the rules with a good enough reason. We recommend following the C++ Core Guidelines, when +it doesn't contradict any of the Google Style Guide or the above exceptions. + +C++ is a powerful language and "with great power comes great responsibility". Please aim for simple, readable and +maintainable solutions and avoid footguns. Be open for respectful debate in pull request reviews. + +Shell script files shall follow the guidelines and best practices defined by the [shellcheck](https://github.com/koalaman/shellcheck) analysis tool. +New contributions are expected to pass the shellcheck analysis as part of the verification process. +If a shellcheck requested change is unfeasable it shall be disabled on per-line basis and will be subjected to review. Review comment: typo: ```suggestion If a shellcheck requested change is unfeasible it shall be disabled on per-line basis and will be subjected to review. ``` -- 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]
