[
https://issues.apache.org/jira/browse/MINIFICPP-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marton Szasz updated MINIFICPP-1617:
------------------------------------
Description:
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 should
improve on this, so I'm not including it in CONTRIB.md.
* 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
was:
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
> 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
> Priority: Major
> 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 should
> improve on this, so I'm not including it in CONTRIB.md.
> * 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)
