doc/CODE-STYLE

   1 Code style in Dinit
   2 ===================
   3
   4 This document presents a brief overview of the style used in the Dinit source code. It may not be
   5 exhaustive. If you would like to contribute, please check this guide and also observe any existing
   6 code style.
   7
   8 1. Line widths - do not exceed 110 characters; try to limit to 100. When wrapping a line, the
   9    indent should be increased by at least two levels on the subsequent lines.
  10
  11 2. Curly braces - for classes and functions, the opening brace appears by itself on an empty line,
  12    as does the closing brace. In other cases the opening brace should appear at the end of the
  13    line (and not on a line by itself). The closing brace always appears on a line by itself.
  14
  15    If curly braces are omitted (for a control statement) then the entire statement should be a
  16    single line. Otherwise the braces are mandatory.
  17
  18        class a
  19        {
  20            void foo()
  21            {
  22                if (true) {
  23                    // ok - braces used
  24                }
  25
  26                if (true) foo(); // ok - same line
  27            }
  28        }
  29
  30 3. Indentation - is 4 spaces per level. Never tabs. Indentation level increases after an opening
  31    curly brace, though for long namespace declarations this is optional.
  32
  33 4. Blank lines - should be used between method and class definitions, and can be used in code
  34    to break it into sections with different concerns. A double blank line should never appear
  35    inside a function, and generally not inside a class, but may be used to indicate a significant
  36    break. Blank lines should never immediately follow an opening curly brace nor precede a
  37    closing curly brace.
  38
  39 5. Exceptions - should be used sparingly. Much of the Dinit code is exception-free and this
  40    needs to be maintained. Functions that cannot throw or propagate exceptions should be marked
  41    as "noexcept".
  42
  43 6. Pointers and references - the rules are a bit loose here, but in general function parameters
  44    which may be modified by the callee should be passed via pointer, to act as a visual aid
  45    in understanding the function semantics.
  46
  47 7. Balance maintainability (including readability) with efficiency. Existing code should serve
  48    as a guide.