Coding Conventions

Code Format

We know that indentation style is a personal matter but the codebase needs to look consistent, so please adhere to the conventions below.

  • Bracket style: largely Stroustrup (Egyptian braces), except for classes, functions, and the like where we prefer to place the opening braces on a new line

  • 4-space indentation, NO TAB CHARACTERS, no trailing spaces

  • Do not align variable names in declaration blocks or multi-line function declarations. They are hard to maintain, and look awkward when very short and very long type names are mixed (e.g. int vs const std::vector<SomeVeryLongTypeName>&).

  • Spaces around if, for, while, return, and other keywords

  • Spaces around =, ==, &&, ||, and other operators

  • No parens around the value in return statements

  • No multi-line blanks within class/functions

  • Non-documentation comments: use // not /**/

The OMNeT++ IDE provides you pre-configured code styles in Window -> Preferences -> C++ -> Code Style. Choose OMNeT++ as your code style. Pressing Ctrl+Shift+F will reformat your code to match this style.

Naming Convention

Rules for variable names, function names, class names, and other identifiers.

  • Use camel case

  • Variables and functions start with lowercase

  • Types start with uppercase

  • Constants and enum values are capitalized, with underscore as word separator

  • Don’t abbreviate (too much)

  • Function names start with a verb

  • Functions returning a bool preferably start with is or has

Commenting

  • Add copyright headers at the top of each source file. Use // comments for consistency with NED and MSG files.

  • Generally, use // comments in the code (except for Doxygen comments)

  • No decorations such as ASCII art or separator lines like ========, -------- or ########

  • For documentation comments (Doxygen and NED), see Documentation Guidelines

Class Layout

Consistent layout of class declarations throughout the project helps maintainers to remain sane.

  • Data members first, protected/private methods next, public methods last

  • Sort data members into configuration (or parameters), state, and statistics sections

  • Methods that are not public API should be private or protected

  • Use Doxygen comments (/** */) for public API only

  • Comment data members with // comments

  • Non-public methods can be left undocumented, or use // comments where necessary

Functions

Misnamed and “kitchen-sink” functions are unfortunately quite common and make the code hard to follow and reason about. Here’s what you can do:

  • Functions should be focused (i.e. do one thing only), and the name should reflect the purpose

  • Try to minimize side effects (modify class members and other non-local state as little as possible)

  • If you cannot find an accurate name for it, it is a strong indicator that the function should not exist in that form (e.g. needs to be split up or the code organized in a different way)

  • If it has a side effect, the name should reflect that (e.g. get methods must not modify state)

  • Local variables should be declared close to their use, in the smallest scope possible (i.e. not C-style, at the top of the function)

  • Commenting: we prefer breaking up the function body into logical blocks and adding a // comment above each block to document its intended purpose

C++ Style

Most users of INET are not C++ scholars. We think the codebase should be written in a style and in a subset of C++ that makes it accessible to our users.

  • Emphasis on readability, i.e. refrain from clever tricks and relatively obscure C++ features

  • Use of the Boost library and other excessively templated code is not allowed

C++11 Features

From INET 3.0, the following C++11 features will be allowed (and recommended):

  • Non-static member initializers (preferred to constructors)

  • auto for iterators

  • nullptr

  • static_assert

  • Range-based for loops

  • final method keyword

  • override method keyword

  • Delegating constructors