|
| 1 | +--- |
| 2 | +BasedOnStyle: Google |
| 3 | +--- |
| 4 | +Language: Cpp |
| 5 | + |
| 6 | +# 1. Two space indentation (never-ever use tabs) |
| 7 | +IndentWidth: 2 |
| 8 | +UseTab: Never |
| 9 | + |
| 10 | +# 2. Max number of columns is 80 |
| 11 | +ColumnLimit: 80 |
| 12 | + |
| 13 | +# 3. No space before parenthesis except for flow control statements |
| 14 | +# (if, for, switch, etc) and sizeof. |
| 15 | +# Warning: It seems there is no option for spacing after sizeof |
| 16 | +SpaceBeforeCaseColon: false |
| 17 | +SpaceBeforeParens: ControlStatements |
| 18 | +SpaceBeforeRangeBasedForLoopColon: true |
| 19 | + |
| 20 | +# 4. Opening and closing braces in the same line as the statement they refer to, |
| 21 | +# preceded by a space (if () {) except for function definitions |
| 22 | +# (opening braces in a new line) |
| 23 | +BreakBeforeBraces: Linux |
| 24 | + |
| 25 | +# 5. Variable declarations at the beginning of the innermost block they are |
| 26 | +# required. |
| 27 | +# Warn: Cannot be tested |
| 28 | + |
| 29 | +# 6. Return type and qualifiers of a function prototype goes in the same line |
| 30 | +# as the function name. |
| 31 | +# 7. Return type and qualifiers of a function definition goes in two separate |
| 32 | +# lines (qualifiers, types, line break, name(...)) |
| 33 | +AlwaysBreakAfterDefinitionReturnType: All |
| 34 | +AlwaysBreakAfterReturnType: AllDefinitions |
| 35 | + |
| 36 | +# 8. If a line is too long (more than 80 chars) we break it according to the |
| 37 | +# following rules: |
| 38 | +# - We break from left to right, until all sublines honor the 80 column limit |
| 39 | +# - Line break increments the indentation level of all sublines in one unit |
| 40 | +# (2 spaces) except the first one |
| 41 | +# - Unary operations are never broken |
| 42 | +# - Binary operations are broken between the first operand and the operation |
| 43 | +# - Ternary operations are broken in three lines, with the first break |
| 44 | +# between the conditional expression and the "?", and the second break |
| 45 | +# right before the ":" |
| 46 | +# - Function calls are broken right after the parenthesis, with every |
| 47 | +# argument in a separate line except if the grouping of certain arguments |
| 48 | +# improves readability (e.g. pairs of I/Q components, groups of 3 spatial |
| 49 | +# coordinates, etc) |
| 50 | +# - Function definitions are broken right after the parenthesis, with every |
| 51 | +# argument definition in a separate line, always. |
| 52 | +BreakBeforeBinaryOperators: NonAssignment |
| 53 | +BreakBeforeTernaryOperators: true |
| 54 | +AllowAllArgumentsOnNextLine: false |
| 55 | +BinPackArguments: false |
| 56 | +AllowAllParametersOfDeclarationOnNextLine: false |
| 57 | +BinPackParameters: false |
| 58 | + |
| 59 | +# 9. Assignments inside conditional statements are allowed, unless it impacts |
| 60 | +# readability |
| 61 | +# Warn: Cannot be tested |
| 62 | + |
| 63 | +# 10. Braceless blocks (i.e. when the body of certain control flow statement |
| 64 | +# consists in only one statement) are preferred, according to the following |
| 65 | +# rules: |
| 66 | +# - The statement itself and its body is separated by a line break, with the |
| 67 | +# body indentation incremented by one unit. |
| 68 | +# - If the statement is an if-else construct, and one of either blocks |
| 69 | +# contain more than 1 statement, both blocks use braces. |
| 70 | +# - If the statement consists of several nested blocks of the same kind, and |
| 71 | +# any of the statement bodies cannot be expressed as a braceless block, all |
| 72 | +# nested blocks use braces. |
| 73 | +# Warn: Cannot be tested. |
| 74 | +# Note: Going by the statements above, one-liners will be avoided. |
| 75 | +AllowShortIfStatementsOnASingleLine: Never |
| 76 | +AllowShortBlocksOnASingleLine: false |
| 77 | +AllowShortCaseLabelsOnASingleLine: false |
| 78 | +AllowShortEnumsOnASingleLine: false |
| 79 | +AllowShortFunctionsOnASingleLine: None |
| 80 | +AllowShortLoopsOnASingleLine: false |
| 81 | +AlignAfterOpenBracket: AlwaysBreak |
| 82 | + |
| 83 | +# 11. Variable names in declarations are not aligned, unless it improves |
| 84 | +# readability. |
| 85 | +# Warn: A general rule must be set. Going for not aligned. |
| 86 | + |
| 87 | +# 12. Structure member names are not aligned, unless it improves readability. |
| 88 | +# Warn: A general rule must be set. Going for not aligned. |
| 89 | + |
| 90 | +# 13. Pointer declarations leave a space between the type and the stars, and no |
| 91 | +# space between the stars and the identifier, or between the stars themselves. |
| 92 | +DerivePointerAlignment: false |
| 93 | +PointerAlignment: Right |
| 94 | + |
| 95 | +# 14. In C code, we favor lower snake case for variables, types and function |
| 96 | +# names. |
| 97 | +# Warn: Cannot be checked. User responsibility. |
| 98 | + |
| 99 | +# 15. In C/C++ code, we favor upper snake case for #defines and enumerated constants. |
| 100 | +# Warn: Cannot be checked. User responsibility. |
| 101 | + |
| 102 | +# 16. Ident preprocessor directives after the hash |
| 103 | +IndentPPDirectives: AfterHash |
0 commit comments