NFD

# NFD code style guidelines

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:

*   (amended 8) Names representing generic template types should be a single uppercase letter

        template<class T> ...

        template<class C, class D> ...

    However, when template parameter represents a certain concept and expected to have a certain interface, the name should be explicitly spelled out:

        template<class FaceBase> ...

        template<class Packet> ...

*   (amended 10)

    Global variables should have `g_` prefix

*   (amended 11)

    **All** class variables should have `m_` prefix.

    Static class variables should have `s_` prefix.

*   (amended 31)

    Exceptions can be used in the code, but should be used only in **exceptional** cases and not in the primary processing path.

    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:

        #include <stdexcept>

        class Foo

        {

            struct Error : std::runtime_exception

            {

                Error(const std::string& what) : std::runtime_error(what) {}

            };

        };

    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.

*   (amended 33)

    We will use only `.cpp` and `.hpp` extensions

*   (removed 35)

    Lines should be within a reasonable range. >100 column-lines should be generally avoided.

*   (removed 44)

    Implicit conversion is generally allowed.

    Implicit conversion between integer and floating point numbers can cause problems and should be avoided.

    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.

    Avoid C-style casts.  Use `static_cast`, `dynamic_cast`, `reinterpret_cast`, `const_cast` instead where appropriate.

*   (amended 68)

    All three presented styles ARE acceptable.  First and third ARE recommended (these are actually GNU styles).

*   (amended 69)

    The class declarations should have the following form:

        class SomeClass : public BaseClass 

        { 

        public: 

          ... <public methods> ...

        protected: 

          ... <protected methods> ...

        private: 

          ... <private methods> ...

        public: 

          ... <public data> ...

        protected: 

          ... <protected data> ...

        private: 

          ... <private data> ...

        };

    ``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.

*   (amended 70)

    When declaring/defining function/method, the return type should be put on a separate line before function/method name.

    Method and function definitions should have the following form:

        void

        someMethod() 

        { 

          ... 

        }

*   (amended 76) No space requirement before : in switch statements

        switch (condition) { 

          case ABC:

            statements; 

            // Fallthrough 

          case DEF: 

            statements; 

            break;

          case XYZ: 

            statements; 

            break; 

          default: 

            statements; 

            break;

        }