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/process/coding-style.rst
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 _t.
32 Yes, _t also means typedef. It's perhaps not ideal.
40 - for full-blown classes, CamelCaps, private: section, accessors,
41 probably not copyable, etc.
43 * Naming > Variable Names:
45 Google uses _ suffix for class members. That's ugly. We'll use
46 a m_ prefix, like so, or none at all.
50 int get_foo() const { return m_foo; }
51 void set_foo(int foo) { m_foo = foo; }
57 * Naming > Constant Names:
59 Google uses kSomeThing for constants. We prefer SOME_THING.
61 * Naming > Function Names:
63 Google uses CamelCaps. We use_function_names_with_underscores().
65 Accessors are the same, {get,set}_field().
67 * Naming > Enumerator Names:
69 Name them like constants, as above (SOME_THING).
71 * Comments > File Comments:
73 Don't sweat it, unless the license varies from that of the project
74 (LGPL2.1 or LGPL3.0) or the code origin isn't reflected by the git history.
77 Indent width is two spaces. When runs of 8 spaces can be compressed
78 to a single tab character, do so. The standard Emacs/Vim settings
81 // -*- mode:C++; tab-width:8; c-basic-offset:2; indent-tabs-mode:t -*-
82 // vim: ts=8 sw=2 smarttab ft=cpp
84 * Formatting > Conditionals:
86 - No spaces inside conditionals please, e.g.
92 - Always use newline following if, and use braces:
95 bar; // like this, even for a one-liner
99 bar; // no, usually harder to parse visually
103 if (foo) { bar; } // definitely no
105 * Header Files -> The `#define` Guard:
107 `#pragma once` is allowed for simplicity at the expense of
108 portability since `#pragma once` is widely supported and is known
109 to work on GCC and Clang.
112 The following guidelines have not been followed in the legacy code,
113 but are worth mentioning and should be followed strictly for new code:
115 * Header Files > Function Parameter Ordering:
117 Inputs, then outputs.
119 * Classes > Explicit Constructors:
121 You should normally mark constructors explicit to avoid getting silent
124 * Classes > Copy Constructors:
126 - Use defaults for basic struct-style data objects.
128 - Most other classes should DISALLOW_COPY_AND_ASSIGN.
130 - In rare cases we can define a proper copy constructor and operator=.
132 * Other C++ Features > Reference Arguments:
134 Only use const references. Use pointers for output arguments.
136 * Other C++ Features > Avoid Default Arguments:
138 They obscure the interface.
144 For new python code, PEP-8 should be observed:
146 https://www.python.org/dev/peps/pep-0008/
148 Existing code can be refactored to adhere to PEP-8, and cleanups are welcome.
151 JavaScript / TypeScript
152 -----------------------
154 For Angular code, we follow the official Angular style guide:
156 https://angular.io/guide/styleguide
158 To check whether your code is conformant with the style guide, we use a
159 combination of ESLint, Codelyzer and Prettier:
162 http://codelyzer.com/