CodeStyle » History » Revision 15
Revision 14 (Alex Afanasyev, 02/27/2014 10:28 AM) → Revision 15/30 (Alex Afanasyev, 03/17/2014 09:50 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 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)
**Private** **All** class variables should have `m_` prefix.
**Static** Static class variables should have `s_` prefix.
* (amended 26)
Allow commonly used abbreviated **next/prev** pair in addition to **next/previous**
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.
* (amended 27)
In cases when full word is too long, a commonly accepted abbreviation can be used. For example, **dest** instead of **destination**.
* (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;
}