Version 43 (modified by jinmei, 8 years ago) (diff)


This page documents some coding guidelines.

Refer also to the BIND 9 coding guidelines. They should be used where they do not conflict with the guidelines on this page. This is because we expect many ISC developers work on both versions of code, and in that case it's easier to maintain the code if the styles are as compatible as possible. Some of the styles derived from BIND 9 that are often forgotten or misunderstood are explicitly mentioned below.

  1. Common
    1. Testing/Documentation addresses and prefixes
    2. XXX vs. TODO Comments
  2. Python Style
    1. Class initializers
  3. C++ Style
    1. File Name Conventions
    2. Ordering Include Files
    3. Tabs & Indentation
    4. Curly Braces
      1. Curly Braces for Return
      2. Curly Braces for Catch
    5. Parentheses
    6. Operators
    7. Operator Overloading
    8. Class Attributes
    9. Non-copyable Classes
    10. Naming
    11. Where to Put Reference and Pointer Operators
      1. Doxygen Comment Style
      2. Explicit \brief for Doxygen
    13. Methods
    14. Namespaces
    15. Consts
    16. Google Test Style
  4. User Interface (UI) Guidelines
    1. IP address and port formatting
  5. Imported Code
  6. Guidelines Adopted by Other Projects
  7. About this Document


Testing/Documentation addresses and prefixes


XXX vs. TODO Comments

We sprinkle comments in code with keywords to indicate pending work. De-facto standards are either XXX or TODO.

In BIND 10, TODO is preferred.

XXX comments that do not refer to potential future changes or improvements should just be comments.

Python Style

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

Class initializers


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

C++ Style

File Name Conventions




Ordering Include Files

We include our own project headers first, then library, and finally system headers, whenever possible. Each header is expected to have any necessary #include statements it needs, and this helps insure that.

#include <dns/message.h> 
#include <boost/shared_ptr.hpp>
#include <string>

Tabs & Indentation



In C++ we use the BSD style (also from BIND 9), where continuing lines are aligned with the corresponding opening parenthesis, like this:

if (JS_DefineProperty(cx, o, "data",
                      STRING_TO_JSVAL(JS_NewStringCopyN(cx, data, res)),
                      NULL, NULL, JSPROP_ENUMERATE) != 0) {

Curly Braces

Always add braces even for a single-line block:

if (something_holds) {
    perform something;
} else if (nonorthogonal_condition) {
    perform otherthing;
    perform finalthing;

Curly Braces for Return

The opening curly brace should occur on the same line as the argument list, unless the argument list is more than one line long.

f(int i) {
    // whatever

g(int i, /* other args here */
  int last_argument)
    return (i * i);

This was derived from the BIND 9 coding guideline. It's known this style may look awkward (and even may look inconsistent) for some, but for the reason stated at the beginning we follow this style.

Curly Braces for Catch

A catch statement should have braces on a single line, like this:

   } catch (const SomeException& ex) { 


Do put a space after 'return', and also parenthesize the return value.

    return 1;   // BAD
    return (1); // Good

This was derived from the BIND 9 coding guideline.


Use operator methods in a readable way. In particular, use the following style with operator==:

    if (x == 10) {  // Good
        // do something that has to be done when x is equal to 10

instead of this:

    if (10 == x) {  // BAD

because the former style is much more readable and intuitive for humans. While the latter style might help detect bugs like dropping one = in the expression, modern compilers with proper warning levels can do the same job more comprehensively. This is especially so for cleanly written C++ code (compared to plain old C).

See also developers' discussions at:

Operator Overloading

Operator overloading is allowed when it's considered intuitive and helpful for improving code readability. But care should be taken, because often it could be only intuitive for that developer who introduced it. If it doesn't look intuitive for the reviewer, the developer has responsibility to convince the reviwer; if it fails the default action is to use non operator method/function for that purpose.

It's recommended to define operator<<(std::ostream& os, const TheClass& obj) if TheClass has operator==() and toText() methods. This allows the class can be used in EXPECT_EQ (and its variants) in googletests.

The following rule was deprecated. It doesn't seem to be followed anyway, and no one remembered why it had been introduced.

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

class Foo {
    // This rule was deprecated.
    //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)

Non-copyable Classes

If you want a class to be non-copyable (neither copy constructor nor assignment), inhert from boost::noncopyable rather than implementing this yourself.




Class names are LikeThis, methods are likeThis(), variables are like_this, and constants are LIKE_THIS. Data class members are like_this_.

Enumerations are written as

enum EnumName {
} enum_instance;

Note that unless you have a specific reason to set specific values, leave specific values off. These can be written if needed:

enum ExamplePortNumbers {
  DNS = 53,
  DHCP = 68

Where to Put Reference and Pointer Operators


int* int_var;
int& int_ref;



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

// As is this.


class Foo {

Doxygen Comment Style

When writing a Doxygen special comment block there are several possible styles:

We use the C++ style of 3-slashes:

/// A lot of examples are called foo().
/// \param baz foo() usually takes an argument
foo(Bar baz) {

Explicit \brief for Doxygen

If you don't use \brief as the first thing in your doxygen comment, then doxygen will turn the first paragraph into a \brief description anyway. However, we include it anyway so that everybody understands that this is the \brief description.



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


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





Use const as much as possible. Make class methods const member functions whenever possible.

If a function has a parameter with a "top-level const", make sure the const appears not only in the definition but also in the declaration. For example, if you define the following function in a .cc file:

foo(const int param) {

then make sure the const appears in the corresponding declaration in a header file (.h):

int foo(const int param);  // const cannot be omitted

Technically, the latter const is redundant. But SunStudio C++ compilers have a bug in name mangling that requires the "consistency":

Unfortunately, we want to be as portable as possible, and so need to work around this by being redundant.

Google Test Style

Try to use EXPECT_<op>() rather than EXPECT_TRUE():

EXPECT_TRUE(run_time > 1);   // BAD

EXPECT_GT(run_time, 1);      // Good

because when the test fails the latter will provide more detailed information (the values of "actual" and "expected").

Note that this is not always possible, especially when checking an object that has no operator<<() (or more obviously no operator<op>()), which is used to output on failure.

User Interface (UI) Guidelines

BIND 10 is a server process, so does not have much that would be considered a user interface. This section discusses what we do have.

IP address and port formatting

Whenever an IP address and port is output, IETF RFC 2396 and RFC 2732 should be followed.

For IPv4 addresses, this looks like this:

For IPv6 addresses, this looks like this:


Imported Code


Guidelines Adopted by Other Projects

Other projects have their own coding guidelines. Here're some examples of such guidelines. These are reference purposes only; unless explicitly stated we also adopt some part of other guidelines, they are not part of the BIND 10's coding guidelines.

About this Document

Creation author and date unknown
Reviewed 2011-09-12
Review scheduled 2012-03-12