[jira] [Created] (MINIFICPP-1617) Update CONTRIB.md where it differs from practice

["Marton Szasz (Jira)" <ji...@apache.org>]

Marton Szasz created MINIFICPP-1617:
---------------------------------------

             Summary: Update CONTRIB.md where it differs from practice
                 Key: MINIFICPP-1617
                 URL: https://issues.apache.org/jira/browse/MINIFICPP-1617
             Project: Apache NiFi MiNiFi C++
          Issue Type: Improvement
            Reporter: Marton Szasz
             Fix For: 0.11.0


CONTRIB.md refers to the google style guide, but the codebase and practice differs from that in many ways.

A quick list:
 * we use .cpp, not .cc for impl files
 * New code should prefer{{ #pragma once}} over include guards.
 * I think forward declarations are fine in the codebase.
 * I think using-directives ({{using namespace}}) are acceptable, but not encouraged in our codebase.
 * We use objects with static storage duration in quite a few places, e.g. processor properties. Most of these don't follow the rule of being trivially destructible and initialized with a constant expression.
 * We use inheritance way more than is recommended by the style guide. I think we should improve this, so will not include as an exception.
 * We're more liberal regarding operator overloading and user-defined literals.
 * We allow public mutable data members
 * We allow functions to be defined inline when it makes sense
 * We have default arguments on virtual functions in many cases.
 * We use rvalue references
 * We use exceptions
 * We use RTTI
 * We use {{gsl::narrow}} and {{gsl::narrow_cast}} in addition to standard casts. We don't use abseil.
 * We're more liberal regarding the use of {{auto}}. The style guide says use it only when it makes the code clearer, but I think we allow using it according to personal preferences.
 * I think we're OK with template metaprogramming as long as the usage is clear.
 * In naming, we use lowerCamelCase for functions, including accessors/mutators and usually UPPER_SNAKE_CASE for constants. For filenames, we usually use the class name or some reasonable name typically in UpperCamelCase, except when it's meant to imitate some other header, like gsl.h. If a type name is imitating something from STL, boost or similar, then STL-style lower_snake_case is used (e.g. {{utils::make_unique}}).
 * Static data members might be named differently than snake_with_trailing_underscore_, I can't recall a good example atm. I think they are snake_case.
 * Enums are either FULL_CAPS_SNAKE or UpperCamelCase.
 * We don't use file-level comments to describe the contents of a file, we only include the license boilerplate.
 * Function comments use Javadoc style {{/** */}}
 * Line length is not really limited, but the linter checks for 200 characters. Use NOLINT comment when it makes sense to have a longer line.
 * continuation indentaion is ok both with 2 levels and aligned



--
This message was sent by Atlassian Jira
(v8.3.4#803005)