]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | Ceph Coding style |
2 | ----------------- | |
3 | ||
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. | |
6 | ||
7 | C code | |
8 | ------ | |
9 | ||
10 | For C code, we conform by the Linux kernel coding standards: | |
11 | ||
12 | https://www.kernel.org/doc/Documentation/CodingStyle | |
13 | ||
14 | ||
15 | C++ code | |
16 | -------- | |
17 | ||
18 | For C++ code, things are a bit more complex. As a baseline, we use Google's | |
19 | coding guide: | |
20 | ||
21 | https://google.github.io/styleguide/cppguide.html | |
22 | ||
23 | ||
24 | As an addendum to the above, we add the following guidelines, organized | |
25 | by section. | |
26 | ||
27 | * Naming > Type Names: | |
28 | ||
29 | Google uses CamelCaps for all type names. We use two naming schemes: | |
30 | ||
31 | - for naked structs (simple data containers), lower case with _d | |
32 | suffix ('d' for data). Not _t, because that means typdef. | |
33 | ||
34 | struct my_type_d { | |
35 | int a, b; | |
36 | my_type_d() : a(0), b(0) {} | |
37 | }; | |
38 | ||
39 | - for full-blown classes, CamelCaps, private: section, accessors, | |
40 | probably not copyable, etc. | |
41 | ||
42 | * Naming > Variable Names: | |
43 | ||
44 | Google uses _ suffix for class members. That's ugly. We'll use | |
45 | a m_ prefix, like so: | |
46 | ||
47 | class Foo { | |
48 | public: | |
49 | int get_foo() const { return m_foo; } | |
50 | void set_foo(int foo) { m_foo = foo; } | |
51 | ||
52 | private: | |
53 | int m_foo; | |
54 | }; | |
55 | ||
56 | * Naming > Constant Names: | |
57 | ||
58 | Google uses kSomeThing for constants. We prefer SOME_THING. | |
59 | ||
60 | * Naming > Function Names: | |
61 | ||
62 | Google uses CamelCaps. We use_function_names_with_underscores(). | |
63 | ||
64 | Accessors are the same, {get,set}_field(). | |
65 | ||
66 | * Naming > Enumerator Names: | |
67 | ||
68 | Name them like constants, as above (SOME_THING). | |
69 | ||
70 | * Comments > File Comments: | |
71 | ||
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. | |
74 | ||
75 | * Formatting > Tabs: | |
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 | |
78 | header is: | |
79 | ||
80 | // -*- mode:C++; tab-width:8; c-basic-offset:2; indent-tabs-mode:t -*- | |
81 | // vim: ts=8 sw=2 smarttab | |
82 | ||
83 | * Formatting > Conditionals: | |
84 | ||
85 | - No spaces inside conditionals please, e.g. | |
86 | ||
87 | if (foo) { // okay | |
88 | ||
89 | if ( foo ) { // no | |
90 | ||
91 | - Always use newline following if: | |
92 | ||
93 | if (foo) | |
94 | bar; // okay, but discouraged... | |
95 | ||
96 | if (foo) { | |
97 | bar; // this is better! | |
98 | } | |
99 | ||
100 | if (foo) bar; // no, usually harder to parse visually | |
101 | ||
102 | ||
103 | ||
104 | ||
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: | |
107 | ||
108 | * Header Files > Function Parameter Ordering: | |
109 | ||
110 | Inputs, then outputs. | |
111 | ||
112 | * Classes > Explicit Constructors: | |
113 | ||
114 | You should normally mark constructors explicit to avoid getting silent | |
115 | type conversions. | |
116 | ||
117 | * Classes > Copy Constructors: | |
118 | ||
119 | - Use defaults for basic struct-style data objects. | |
120 | ||
121 | - Most other classes should DISALLOW_COPY_AND_ASSIGN. | |
122 | ||
123 | - In rare cases we can define a proper copy constructor and operator=. | |
124 | ||
125 | * Other C++ Features > Reference Arguments: | |
126 | ||
127 | Only use const references. Use pointers for output arguments. | |
128 | ||
129 | * Other C++ Features > Avoid Default Arguments: | |
130 | ||
131 | They obscure the interface. |