Project

General

Profile

CodeStyle » History » Version 7

Alex Afanasyev, 01/27/2014 09:29 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
* (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 7 Alex Afanasyev
* (removed 35). Lines should be within a reasonable range. >100 column-lines should be generally avoided.
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
        }