4 Coding style is most important for new code and (to a lesser extent)
5 revised code. It is not worth the churn to simply reformat old code.
10 For C code, we conform by the Linux kernel coding standards:
12 https://www.kernel.org/doc/Documentation/CodingStyle
18 For C++ code, things are a bit more complex. As a baseline, we use Google's
21 https://google.github.io/styleguide/cppguide.html
24 As an addendum to the above, we add the following guidelines, organized
27 * Naming > Type Names:
29 Google uses CamelCaps for all type names. We use two naming schemes:
31 - for naked structs (simple data containers), lower case with _d
32 suffix ('d' for data). Not _t, because that means typdef.
36 my_type_d() : a(0), b(0) {}
39 - for full-blown classes, CamelCaps, private: section, accessors,
40 probably not copyable, etc.
42 * Naming > Variable Names:
44 Google uses _ suffix for class members. That's ugly. We'll use
49 int get_foo() const { return m_foo; }
50 void set_foo(int foo) { m_foo = foo; }
56 * Naming > Constant Names:
58 Google uses kSomeThing for constants. We prefer SOME_THING.
60 * Naming > Function Names:
62 Google uses CamelCaps. We use_function_names_with_underscores().
64 Accessors are the same, {get,set}_field().
66 * Naming > Enumerator Names:
68 Name them like constants, as above (SOME_THING).
70 * Comments > File Comments:
72 Don't sweat it, unless the license varies from that of the project
73 (LGPL2) or the code origin isn't reflected by the git history.
76 Indent width is two spaces. When runs of 8 spaces can be compressed
77 to a single tab character, do so. The standard Emacs/Vim settings
80 // -*- mode:C++; tab-width:8; c-basic-offset:2; indent-tabs-mode:t -*-
81 // vim: ts=8 sw=2 smarttab
83 * Formatting > Conditionals:
85 - No spaces inside conditionals please, e.g.
91 - Always use newline following if:
94 bar; // okay, but discouraged...
97 bar; // this is better!
100 if (foo) bar; // no, usually harder to parse visually
105 The following guidelines have not been followed in the legacy code,
106 but are worth mentioning and should be followed strictly for new code:
108 * Header Files > Function Parameter Ordering:
110 Inputs, then outputs.
112 * Classes > Explicit Constructors:
114 You should normally mark constructors explicit to avoid getting silent
117 * Classes > Copy Constructors:
119 - Use defaults for basic struct-style data objects.
121 - Most other classes should DISALLOW_COPY_AND_ASSIGN.
123 - In rare cases we can define a proper copy constructor and operator=.
125 * Other C++ Features > Reference Arguments:
127 Only use const references. Use pointers for output arguments.
129 * Other C++ Features > Avoid Default Arguments:
131 They obscure the interface.