CodeStyle » History » Version 12
Alex Afanasyev, 02/25/2014 05:50 PM
| 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 | 8 | Junxiao Shi | * (amended 31) |
| 28 | Exceptions can be used in the code, but should be used only in **exceptional** cases and not in the primary processing path. |
||
| 29 | |||
| 30 | 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: |
||
| 31 | |||
| 32 | 5 | Alex Afanasyev | #include <stdexcept> |
| 33 | 1 | Junxiao Shi | |
| 34 | class Foo |
||
| 35 | 5 | Alex Afanasyev | { |
| 36 | 1 | Junxiao Shi | struct Error : std::runtime_exception |
| 37 | { |
||
| 38 | Error(const std::string& what) : std::runtime_error(what) {} |
||
| 39 | }; |
||
| 40 | }; |
||
| 41 | |||
| 42 | 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. |
| 43 | 1 | Junxiao Shi | |
| 44 | 8 | Junxiao Shi | * (amended 33) |
| 45 | We will use only `.cpp` and `.hpp` extensions |
||
| 46 | 1 | Junxiao Shi | |
| 47 | 8 | Junxiao Shi | * (removed 35) |
| 48 | Lines should be within a reasonable range. >100 column-lines should be generally avoided. |
||
| 49 | |||
| 50 | * (removed 44) |
||
| 51 | Implicit conversion is generally allowed. |
||
| 52 | |||
| 53 | Implicit conversion between integer and floating point numbers can cause problems and should be avoided. |
||
| 54 | |||
| 55 | 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. |
||
| 56 | |||
| 57 | Avoid C-style casts. Use `static_cast`, `dynamic_cast`, `reinterpret_cast`, `const_cast` instead where appropriate. |
||
| 58 | |||
| 59 | * (amended 68) |
||
| 60 | All three presented styles ARE acceptable. First and third ARE recommended (these are actually GNU styles). |
||
| 61 | |||
| 62 | * (amended 69) |
||
| 63 | The class declarations should have the following form: |
||
| 64 | |||
| 65 | 3 | Alex Afanasyev | class SomeClass : public BaseClass |
| 66 | 4 | Junxiao Shi | { |
| 67 | 3 | Alex Afanasyev | public: |
| 68 | 4 | Junxiao Shi | ... <public methods> ... |
| 69 | 3 | Alex Afanasyev | protected: |
| 70 | ... <protected methods> ... |
||
| 71 | private: |
||
| 72 | 1 | Junxiao Shi | ... <private methods> ... |
| 73 | |||
| 74 | public: |
||
| 75 | ... <public data> ... |
||
| 76 | 3 | Alex Afanasyev | protected: |
| 77 | ... <protected data> ... |
||
| 78 | private: |
||
| 79 | ... <private data> ... |
||
| 80 | }; |
||
| 81 | |||
| 82 | ``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. |
||
| 83 | |||
| 84 | 8 | Junxiao Shi | * (amended 70) |
| 85 | When declaring/defining function/method, the return type should be put on a separate line before function/method name. |
||
| 86 | |||
| 87 | Method and function definitions should have the following form: |
||
| 88 | 3 | Alex Afanasyev | |
| 89 | void |
||
| 90 | someMethod() |
||
| 91 | { |
||
| 92 | ... |
||
| 93 | 1 | Junxiao Shi | } |
| 94 | 9 | Alex Afanasyev | |
| 95 | * (amended 76) No space requirement before : in switch statements |
||
| 96 | |||
| 97 | switch (condition) { |
||
| 98 | case ABC: |
||
| 99 | statements; |
||
| 100 | // Fallthrough |
||
| 101 | |||
| 102 | case DEF: |
||
| 103 | statements; |
||
| 104 | break; |
||
| 105 | |||
| 106 | case XYZ: |
||
| 107 | statements; |
||
| 108 | break; |
||
| 109 | |||
| 110 | default: |
||
| 111 | statements; |
||
| 112 | break; |
||
| 113 | } |