CodeStyle » History » Version 5
Alex Afanasyev, 01/26/2014 11:41 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 | * (amended 10). Global variables should have `g_` prefix |
||
| 6 | * (amended 11). **All** class variables should have `m_` prefix. Static class variables should have `s_` prefix. |
||
| 7 | 5 | Alex Afanasyev | * (amended 31). Thrown exceptions can be either suffixed with ``Exception`` (SecurityException) or ``Error`` (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: |
| 8 | |||
| 9 | #include <stdexcept> |
||
| 10 | |||
| 11 | class Foo |
||
| 12 | { |
||
| 13 | struct Error : std::runtime_exception |
||
| 14 | { |
||
| 15 | Error(const std::string& what) : std::runtime_error(what) {} |
||
| 16 | }; |
||
| 17 | }; |
||
| 18 | |||
| 19 | 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. |
||
| 20 | |||
| 21 | 1 | Junxiao Shi | * (amended 33). We will use only `.cpp` and `.hpp` extensions |
| 22 | 3 | Alex Afanasyev | * (amended 35). File content should be kept within 80 columns. OK if some occasionally some lines exceed this limit. |
| 23 | 1 | Junxiao Shi | * (amended 44). Avoid C-style casts. Use `static_cast`, `dynamic_cast`, `reinterpret_cast`, `const_cast` where appropriate instead. |
| 24 | * (new). Exceptions can be used in the code, but should be used only in **exceptional** cases and not in the primary processing path. |
||
| 25 | * (new). When declaring/defining function/method, the return type should be put on a separate line before function/method name. |
||
| 26 | 4 | Junxiao Shi | * (amended 68). All three presented styles ARE acceptable. First and third ARE recommended (these are actually GNU styles). |
| 27 | 3 | Alex Afanasyev | * (amended 69). The class declarations should have the following form: |
| 28 | |||
| 29 | class SomeClass : public BaseClass |
||
| 30 | { |
||
| 31 | public: |
||
| 32 | 4 | Junxiao Shi | ... <public methods> ... |
| 33 | 3 | Alex Afanasyev | protected: |
| 34 | 4 | Junxiao Shi | ... <protected methods> ... |
| 35 | 3 | Alex Afanasyev | private: |
| 36 | ... <private methods> ... |
||
| 37 | |||
| 38 | public: |
||
| 39 | ... <public data> ... |
||
| 40 | protected: |
||
| 41 | ... <protected data> ... |
||
| 42 | private: |
||
| 43 | ... <private data> ... |
||
| 44 | }; |
||
| 45 | |||
| 46 | 4 | Junxiao Shi | ``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. |
| 47 | 3 | Alex Afanasyev | |
| 48 | * (amended 70) Method and function definitions should have the following form: |
||
| 49 | |||
| 50 | void |
||
| 51 | someMethod() |
||
| 52 | { |
||
| 53 | ... |
||
| 54 | } |