Coding guidelines

We rely heavily on the Google C++ Style Guide. Unless stated otherwise on this page, please follow the Google guidelines.

Memory management

We largely agree with the Google guidelines here, so please follow them. A few remarks:

• the first question to ask yourself is: do I need a pointer here? For example, unless you are using virtual functions or your objects are not movable, you can usually place objects directly into a standard library container, without adding an extra level of indirection.
• do not try to manage memory yourself: code containing the "delete" instruction is likely to be rejected as it indicates that memory management is done without using smart pointers
• when using smart pointers, always prefer unique_ptr over shared_ptr. unique_ptr indicates clearly who owns the memory, making the code easier to follow. You can in some rare cases use shared_ptr, but be ready to justify why.
• avoid defining your own destructors / copy operators / move operators, unless interacting with a C interface. Using smart pointers usually make this superfluous. If you have to define one (be ready to justify why!), also define the others.
• explicitly = delete copy operators (often the case) or move operator (less often the case) if you do not need them. If you want to authorize copy / move, it is better to explicitly set them to = default.

Template meta-programming and SFINAE

We consider the Google guidelines to be too conservative about this. It is okay to use templates when:

• performance is an issue
• it greatly reduces the amount of code / makes the interface much more flexible

However remain careful when using them as they increase executable size and compilation time. When possible, prefer explicit template instantiation to huge header files.

Implementing methods in .h files and inlining

We actually encourage it when the method is critical for performance (e.g. the method will be called many times for each packet) and would potentially benefit from being inlined. Do not explicitly use the inline keyword, let the compiler make the decision.

Virtual functions

Please follow H. Sutter's guidelines on virtuality. In particular, try to keep public interfaces non-virtual. When using virtual functions in critical parts of the code, keep in mind the performance overhead. In particular, virtual function calls cannot be inlined.

Prefer alias declarations (using) to typedef's

For the sake of consistency. typedef's don't support templatization, but alias declarations do.

Unit tests

We try to keep unit test coverage high. If you add a new functionality, please write corresponding class unit tests. We will soon introduce a Github status check measuring code coverage for each new pull requests. Pull requests with insufficient coverage (< 80%) will be rejected.

Formatting

The Google guidelines generally apply. Watch out for the following:

• use 2-space indentation
• namespaces do not introduce an extra indentation level
• limit vertical whitespaces. This is achieved by avoiding extra blank lines (except when then truly help readability) and by avoiding returns before opening braces.

Include guards

All header files are protected by an include guard, which consists of a project prefix followed by the file name. Look at existing header files for guidance.

Apache license header

Do not forget to include it in each new source file!