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