NFD

CodeStyle » History » Revision 9

Revision 8 (Junxiao Shi, 02/16/2014 12:03 AM) → Revision 9/30 (Alex Afanasyev, 02/17/2014 11:57 AM)

# 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 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; 
         }