Version 64 (modified by Gedare, on Jun 2, 2014 at 6:02:37 PM) (diff)

/* Robustness */

Coding Conventions

The style of RTEMS is generally consistent in the core areas. This page attempts to capture generally accepted practices. When in doubt, consult the code around you or look in cpukit/rtems. See the sister page Doxygen Recommendations for examples that illustrate style rules and Doxygen usage.

Source Documentation

  • Use Doxygen according to our Doxygen Recommendations.
  • Use /* */ comments.
  • Start each file with a brief description followed by a license. See Boilerplate File Header.
  • Use comments wisely within function bodies, to explain or draw attention without being verbose.
  • Use English and strive for good grammar, spelling, and punctuation.
  • Use TODO: with a comment to indicate code that needs improvement. Make it clear what there is to do.
  • Use XXX or FIXME to indicate an error/bug/broken code.


  • The RTEMS License is the typical and preferred license.
    • 2- and 3-clause BSD, MIT, and other OSI-approved non-copyleft licenses that permit statically linking with code of different licenses are acceptable.
    • GPL licensed code is NOT acceptable, neither is LGPL. See this blog post explanation for more information.
    • Advertising obligations are NOT acceptable, but restrictions are permissible.

Language and Compiler

  • Use C99.
  • Favor C, but when assembly language is required use inline assembly if possible.
  • Do not use compiler extensions.
  • Pay attention to warnings. Strive to eliminate them.
  • Use RTEMS_ZERO_LENGTH_ARRAY when defining variable-length objects.
  • Use NULL for the null pointer, and prefer to use explicit checks against NULL, e.g. 'if ( ptr != NULL )' instead of 'if ( !ptr )'.
  • Use '(void) unused;' to mark unused parameters.


  • Use spaces instead of tabs.
  • Use two spaces for indentation, four spaces for hanging indentation.
  • Adhere to a limit of 80 characters per line.
  • Put function return types and names on one line if they fit. Put function calls on one line if they fit. If not, put each function argument on its own line with no argument on the first line, and put the closing parenthesis on its own line.
  • No space between a function name and the opening parens.
  • Put braces one space after the conditional expression ends.
  • Put a single space inside and outside of each parenthesis of a conditional expression.
  • Put a single space before and after binary operators.
  • Put a single space before and no space between unary operators (e.g. *, &, !, ~).
  • No spaces around dereferencing operators (-> and .).
  • Do not use more than one blank line in a row.
  • Do not use trailing whitespace at the end of a line.


  • Understand and follow the naming rules.
  • Use typedef to remove 'struct', but do not use typedef to hide pointers.
  • Do not mix variable declarations and code.
  • Declare variables at the start of a block.
  • Only use primitive initialization of variables at their declarations. Avoid complex initializations or function calls in variable declarations.
  • Do not put unrelated functions or data in a single file.
  • Do not declare functions inside functions.
  • Avoid deep nesting by using early returns
    • Parameter checking should be done first with early error returns.
    • Avoid allocation and critical sections until error checking is done.
    • For error checks that require locking, do the checks early after acquiring locks.
    • Use of 'goto' requires good reason and justification.
  • Test and action should stay close together.
  • Avoid complex logical expressions in ifs, fors, and whiles
  • Favor inline functions to hide compile-time feature-conditioned compilation?.
  • Declare and define inline functions in one place. Usually this is a *impl.h file.
  • Declare and define static functions in one place. Minimize forward declarations of static functions.
  • Avoid excess parentheses. Learn the operator precedence rules.
  • Always use parentheses with sizeof. This is an exception to the rule about excess parentheses.


  • Check all return statuses.
  • Use debug assertions (assert).
  • Use const when appropriate for read-only function parameters and compile-time constant values.
  • Do not hard code limits such as maximum instances into your code.
  • Prefer to use sizeof(variable) instead of sizeof(type).
  • Favor C automatic variables over global or static variables.
  • Use global variables only when necessary and ensure atomicity of operations.
  • Do not shadow variables.
  • Avoid declaring large buffers or structures on the stack.
  • Favor mutual exclusion primitives over disabling preemption.
  • Avoid unnecessary dependencies, such as by not calling printf() on error paths.
  • Avoid inline functions and macros with complicated logic and decision points.
  • Prefer inline functions, enum, and const variables instead of CPP macros.
  • CPP macros should use a leading underscore for parameter names and avoid macro pitfalls.


  • Think portable! RTEMS supports a lot of target hardware.
  • For integer primitives, prefer to use precise-width integer types from C99 stdint.h.
  • Write code that is 16-bit, 32-bit, and 64-bit friendly.


  • Minimize modifications to third party code.
  • Keep it simple! Simple code is easier to debug and easier to read than clever code.
  • Share code with other architectures, cpus, and BSPs where possible.
  • Do not duplicate standard OS or C Library routines.


  • Use algorithms with the lowest order of execution. By favoring O(constant) over O(n) algorithms, RTEMS works hard to ensure deterministic execution times as much as possible.
  • If you need to temporarily change the execution mode of a task/thread, restore it.
  • If adding code to cpukit be sure the filename is unique since all files under that directory get merged into a single library.
  • Limit execution times in Interrupt and Timer Service Routines (TSRs). TSRs scheduled by rtems_timer_fire_XXX run in the context of the clock tick ISR while TSRs scheduled by rtems_timer_server_fire_XXX run in the context of a dedicated Timer Server task. Either way, excessive execution times could have a negative impact on the system performance.


TBD: add something about the dependencies and header file layering.

=Exceptions to the Rules=

  • Minimize reformatting existing code in RTEMS unless the file undergoes substantial non-style changes.
  • Third-party code should not be reformatted to fit RTEMS style. Exception: unmaintained third-party code adopted and maintained by RTEMS may be reformatted, subject to the above rules.

Attachments (1)

Download all attachments as: .zip