[MINIFICPP-1617] Update CONTRIB.md where it differs from practice

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 0.11.0
• Assignee: Marton Szasz
• Reporter: Marton Szasz
• Created: 28/Jul/21 11:10
• Updated: 05/Aug/21 15:36
• Resolved: 05/Aug/21 15:36

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