Version 19 (modified by shane, 9 years ago) (diff)

Added review information

This page documents some coding guidelines.


Testing/Documentation? addresses and prefixes

Use and 2001:db8::/32 for purposes like addresses used in test cases or examples in documentation. Likewise, use reserved example domain names such as, .test, .example, etc for domain names used in these cases. They are reserved by specifications and should be the safest in terms of collision avoidance.

Python Style

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

Class initializers

In Python, the __init__() method should be the first one declared in a class definition, like this:

class foo:
    # constructor definition here
    def __init__(self):
    # other functions may follow
    def bar(self):

C++ Style

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

File Name Conventions

Use .cc for C++ source files. This is basically a mere preference and to ensure consistency throughout the package.

Use .h for C++ header files. This is because we may want to provide a C-callable wrapper for some APIs, and some C++ header files are to be included in a C source file. In that case C-compatible file names will look more natural.

Use all all-lowercase characters for file names. This is consistent with the current recommendation for python, and so it will make the file name convention consistent throughout the BIND10 source tree. Not mixing lower/upper cases will also help avoid name conflicts in a case insensitive file system. Note that this policy may not compatible with C++ class name convention (see below) if the file name is based on the class name (e.g., name "" for the definition of the "Myclass" classs). We explicitly accept the conflict, but note that this means it will effectively prohibit mixing cases in class names ("Myclass" and "MyClass" may not coexist).

Tabs & Indentation

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

Indentation at each level is 4 spaces for C++ and Python, other languages should use what is "usual and expected."

Curly Braces

Always add braces even for a single-line block:

if (something_holds) {
    perform something;
} else if (nonorthogonal_condition) {
    perform otherthing;
} else { // optionally comment to clarify the fully orthogonal case
    perform finalthing;

Operator Overloading

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

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

Class Attributes

Accessors for class attributes should be called getXxx().

Mutators for class attributes should be called setXxx().

(where xxx is the attribute)


Don't start things with underscores. According to Stroustrup's C++ book:

Names starting with an underscore are reserved for special facilities in the implementation and the run-time environment, so such names should not be used in application programs.

Class names are LikeThis, methods are likeThis(), variables are like_this, and constants are LIKE_THIS.

Enumerations are written as

enum EnumName {
  THING_ONE = 1,
} enum_instance;

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;
int& int_ref;


Multiline comments can be written in C++ or C style (that is, with or /* */ marks).

 * This is a comment.  It is important probably.
// This is a comment.  It is important probably.
/* This is also ok. */

// As is this.

Comments at the end of lines should usually be C++ style:

class Foo {
    int bar_length;  // The length of the bar in millimeters.


For methods where the arguments all fit on one line with the curly brace, it should be written on one line:

methodName(int argument_one, std::string message) {

Where this is not possible the curly brace should go on a line by itself:

methodName(int argument_one, std::string message,
           int another_argument)


Namespaces will be lower case: isc::dns, or isc::cc.

using namespace should never be used in a header file. They may be used in .cc source files.

Imported Code

If you import code from another project, try to continue the style of the imported project if changes need to be made. This is for two reasons, one is to make merging future versions easier. The other is the encouragement of submitting changes upstream.

Guidelines Adopted by Other Projects

About this Document

Creation author and date unknown
Review scheduled 2010-06-18