Skip to content

Latest commit

 

History

History
86 lines (64 loc) · 4.19 KB

CodingConventions.md

File metadata and controls

86 lines (64 loc) · 4.19 KB
Raw
layout title underMenu
page
Coding Conventions
Development

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