openbmc/docs/cpp-style-and-conventions.md

15 1.  Code should be clear and concise.
16 2.  Code should be written with modern practices.
17 3.  Code should be performant.
19 ### Code should be clear and concise
24 for the writer. Solutions should avoid tricks that detract from the clarity of
31 When there is a conflict between clarity and conciseness, clarity should win
34 ### Code should be written with modern practices
37 standards. Today, that means all C++ code should be compiled using C++23
55 ### Code should be performant.
108 2. Implementers should include the lowest level header required to solve the
113 3. The module used should not have an equivalent in the std namespace that meets
115    should be preferred over boost::chrono. std::array over boost::array.
135 - Line length should be limited to 80 characters.
136 - Indentation should be done with 4 space characters.
137 - Files should use Unix-style newlines (\n).
181 - Even one line conditional and loop statements should have brackets.
197 - Content within a namespace should be at the same indentation level as the
209 - Content within a class / struct should be indented.
219 - Content within a function / conditional / loop should be indented.
234 - Switch / case statements should be indented.
253 - Labels should be indented so they appear at 1 level less than the current
255   labels are preferred or should be regularly used, but simply when they are
281 - Acronyms should be same-case throughout and follow the requirements as in
315 - C++ headers should end in ".hpp". C headers should end in ".h".
316 - C++ files should be named with lower_snake_case.
321 - Structs, classes, enums, and typed template parameters should all be in
325   conventions (`using type = T`) while a multi-word type alias should be
328   STL or an underlying C library it is abstracting. Application APIs should all
345 - Variables should all be lowerCamelCase, including class members, with no
350 - Functions should all be lowerCamelCase.
352   STL or an underlying C library it is abstracting. Application APIs should all
357 - Constants and enum members should be named like variables in lowerCamelCase.
361 - Namespaces should be lower_snake_case.
362 - Top-level namespace should be named based on the containing repository.
427 - Long lines should have continuation start at the same level as the parens or
428   all all items inside the parens should be at a 2-level indent.