CodeStyle » History » Version 13
Alex Afanasyev, 02/27/2014 10:27 AM
1 | 1 | Junxiao Shi | # NFD code style guidelines |
---|---|---|---|
2 | |||
3 | NFD adopts [NDN Platform C++, C, C#, Java and JavaScript Code Guidelines](http://named-data.net/codebase/platform/documentation/ndn-platform-development-guidelines/cpp-code-guidelines/), with the following exceptions: |
||
4 | |||
5 | 10 | Alex Afanasyev | * (amended 8) Names representing generic template types should be a single uppercase letter |
6 | |||
7 | template<class T> ... |
||
8 | template<class C, class D> ... |
||
9 | |||
10 | However, when template parameter represents a certain concept and expected to have a certain interface, the name should be explicitly spelled out: |
||
11 | |||
12 | template<class FaceBase> ... |
||
13 | template<class Packet> ... |
||
14 | |||
15 | 8 | Junxiao Shi | * (amended 10) |
16 | Global variables should have `g_` prefix |
||
17 | 1 | Junxiao Shi | |
18 | 8 | Junxiao Shi | * (amended 11) |
19 | **All** class variables should have `m_` prefix. |
||
20 | Static class variables should have `s_` prefix. |
||
21 | |||
22 | 11 | Alex Afanasyev | * (amended 26) |
23 | Allow commonly used abbreviated **next/prev** pair in addition to **next/previous** |
||
24 | |||
25 | 12 | Alex Afanasyev | Pair **insert/erase** should be used for any new code, already implemented code can keep **insert/delete** if it does not conflict with C++ delete keyword. |
26 | |||
27 | 13 | Alex Afanasyev | * (amended 27) |
28 | In cases when full word is too long, a commonly accepted abbreviation can be used. For example, **dest** instead of **destination*. |
||
29 | |||
30 | 8 | Junxiao Shi | * (amended 31) |
31 | Exceptions can be used in the code, but should be used only in **exceptional** cases and not in the primary processing path. |
||
32 | |||
33 | Exceptions can be suffixed with either `Exception` (eg. SecurityException) or `Error` (eg. SecurityError). Alternatively (and it is a recommended method), one should declare exception class `Exception` or `Error` as an inner class, from which the exception is thrown. For example, when declaring class Foo that can throw errors, one can write the following: |
||
34 | |||
35 | 5 | Alex Afanasyev | #include <stdexcept> |
36 | 1 | Junxiao Shi | |
37 | class Foo |
||
38 | 5 | Alex Afanasyev | { |
39 | 1 | Junxiao Shi | struct Error : std::runtime_exception |
40 | { |
||
41 | Error(const std::string& what) : std::runtime_error(what) {} |
||
42 | }; |
||
43 | }; |
||
44 | |||
45 | 8 | Junxiao Shi | In addition to that, if class Foo is a base class or interface for some class hierarchy, then child classes should should define their own `Error` or `Exception` classes that are inherited from the parent's Error class. |
46 | 1 | Junxiao Shi | |
47 | 8 | Junxiao Shi | * (amended 33) |
48 | We will use only `.cpp` and `.hpp` extensions |
||
49 | 1 | Junxiao Shi | |
50 | 8 | Junxiao Shi | * (removed 35) |
51 | Lines should be within a reasonable range. >100 column-lines should be generally avoided. |
||
52 | |||
53 | * (removed 44) |
||
54 | Implicit conversion is generally allowed. |
||
55 | |||
56 | Implicit conversion between integer and floating point numbers can cause problems and should be avoided. |
||
57 | |||
58 | Implicit conversion in single-argument constructor is usually undesirable. Therefore, all single-argument constructors should be marked 'explicit', unless implicit conversion is desirable. In that case, a comment should document the reason. |
||
59 | |||
60 | Avoid C-style casts. Use `static_cast`, `dynamic_cast`, `reinterpret_cast`, `const_cast` instead where appropriate. |
||
61 | |||
62 | * (amended 68) |
||
63 | All three presented styles ARE acceptable. First and third ARE recommended (these are actually GNU styles). |
||
64 | |||
65 | * (amended 69) |
||
66 | The class declarations should have the following form: |
||
67 | |||
68 | 3 | Alex Afanasyev | class SomeClass : public BaseClass |
69 | 4 | Junxiao Shi | { |
70 | 3 | Alex Afanasyev | public: |
71 | 4 | Junxiao Shi | ... <public methods> ... |
72 | 3 | Alex Afanasyev | protected: |
73 | ... <protected methods> ... |
||
74 | private: |
||
75 | 1 | Junxiao Shi | ... <private methods> ... |
76 | |||
77 | public: |
||
78 | ... <public data> ... |
||
79 | 3 | Alex Afanasyev | protected: |
80 | ... <protected data> ... |
||
81 | private: |
||
82 | ... <private data> ... |
||
83 | }; |
||
84 | |||
85 | ``public``, ``protected``, ``private`` may be repeated several times without interleaving (e.g. public, public, public, private, private) if this allows better readability of the code. |
||
86 | |||
87 | 8 | Junxiao Shi | * (amended 70) |
88 | When declaring/defining function/method, the return type should be put on a separate line before function/method name. |
||
89 | |||
90 | Method and function definitions should have the following form: |
||
91 | 3 | Alex Afanasyev | |
92 | void |
||
93 | someMethod() |
||
94 | { |
||
95 | ... |
||
96 | 1 | Junxiao Shi | } |
97 | 9 | Alex Afanasyev | |
98 | * (amended 76) No space requirement before : in switch statements |
||
99 | |||
100 | switch (condition) { |
||
101 | case ABC: |
||
102 | statements; |
||
103 | // Fallthrough |
||
104 | |||
105 | case DEF: |
||
106 | statements; |
||
107 | break; |
||
108 | |||
109 | case XYZ: |
||
110 | statements; |
||
111 | break; |
||
112 | |||
113 | default: |
||
114 | statements; |
||
115 | break; |
||
116 | } |