wiki:CodingGuidelines

Version 7 (modified by jinmei, 10 years ago) (diff)

--

This page documents some coding guidelines.

Python Style

For Python coding, we will use the Python style guidelines:

http://www.python.org/dev/peps/pep-0008/

C++ Style

You can also see the BIND 9 coding guidelines for comparison.

File Name Conventions

C++ source file: .cc or .cpp, or others?

C++ header file: .hh or .h or others?

Tabs & Indentation

Do not use hard tabs. (Commits may be prevented by a Subversion pre-commit hook.)

Indentation at each level is 4 spaces.

Curly Braces

Always add braces even for a single-line block:

if (something_holds) {
    perform something;
}

Operator Overloading

When a class supports operator overloading, then there should also be non-overloaded methods, like this:

class Foo 
{
public:
    bool equals(const Foo &other) const;
    bool operator==(const Foo &other) const { return equals(other); }        
}

Class Attributes

Accessors for class attributes should be called get_xxx().

Mutators for class attributes should be called set_xxx().

Naming

Please don't start things with underscores (even for private member variables?).

Jinmei has been using CamelCase for class names, and lowercase_with_underscores for methods and variables.

Exceptions

When and how to use C++ exceptions?

Where to Put Reference and Pointer Operators

In C++, it seems to be more common to not insert a space between the type and the operator:

int* int_var;

In C, we normally add a space between them:

int *int_var;

What would we do for BIND10?

Comments

Allow C-style comments?

Namespaces

Whether and how to use our private namespaces (e.g. ISC::DNS::Name).

Whether or not to allow omitting standard namespaces (i.e., whether to allow using namespace std;)

Imported Code

If you import code from another project, don't bother to change the code to match our guidelines unless you plan on editing it relatively heavily.