CodeStyle » History » Version 15
Alex Afanasyev, 03/17/2014 09:50 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 | 15 | Alex Afanasyev | **Private** class variables should have `m_` prefix. |
| 20 | **Static** class variables should have `s_` prefix. |
||
| 21 | 8 | Junxiao Shi | |
| 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 | 14 | Alex Afanasyev | In cases when full word is too long, a commonly accepted abbreviation can be used. For example, **dest** instead of **destination**. |
| 29 | 13 | Alex Afanasyev | |
| 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 | } |