Coding Style

From ReactOS Wiki
Revision as of 03:59, 2 July 2013 by Cybird (talk | contribs) (Clean this up a bit until (if) the new Coding Style gets published.)
Jump to: navigation, search

The ReactOS Project currently enforces very few rules for coding style.

3rd party code

ReactOS uses code from other projects (e.g., Wine). In these instances the following guidelines do not apply and the existing style should be used. This allows easier syncing of future changes.


Formatting should be done separately from code changes. Patches or commits that only change formatting should indicate so (e.g., "Formatting, no code changes", [FORMATTING] label).


One level of indentation is 4 columns. Spaces must be used.


Braces must be placed on their own lines. They must be at the same indentation level as the previous statement. Braces are optional if only one statement is enclosed in it, excepting when a comment is also present.


if (foo()) {

if (foo())
    /* Comment */


if (foo())

if (foo())

if (foo())
    /* Comment */

Long lines

80 columns should be used as a guide for line length.

  • When a line with function call is less than 80 chars long, params should be written on the same line
  • When a line with function call is more than 80 chars long (because calling func has many params), it maybe wise to write params as column, writing comments for each param (when it is needed)

File structure

The usual source code file consists of the following parts (some sections can be omitted if they are empty):

  • The header (an example)
  * PROJECT:         ReactOS Kernel
  * LICENSE:         GPL - See COPYING in the top level directory
  * FILE:            ntoskrnl/ob/namespce.c
  * PURPOSE:         Manages all functions related to the Object Manager name-
  *                  space, such as finding objects or querying their names.
  * PROGRAMMERS:     Alex Ionescu (
  *                  Eric Kohl
  *                  Thomas Weidenmueller (
  • Includes section, which has all #include statements, and vital defines (like #define NDEBUG)
 /* INCLUDES ******************************************************************/
  • Defines section, for per-file defines
 /* DEFINES *******************************************************************/
  • Private (not exported, or used only within the scope of this file) functions
 /* PRIVATE FUNCTIONS ******************************************************/
  • Public functions (if it's a DLL, or a driver)
 /* PUBLIC FUNCTIONS **********************************************************/
  • Or just this way, if it's a standalone app
 /* FUNCTIONS *****************************************************************/
  • [OPTIONAL?]File ends with
 /* EOF */<NewLineCharacterOnYourPlatform>

The Rules

Example of standard API header, please don't make up your own until really necessary:

 * @name SomeAPI
 * @implemented NT4
 * Do nothing for 500ms.
 * @param SomeParameter
 *        Description of the parameter. Wrapped to more lines on ~70th
 *        column.
 * @param YetAnotherParameter
 *        Bleh, bleh :)
 * @return STATUS_SUCCESS in case of success, STATUS_UNSUCCESSFUL
 *         othwerwise.
 * @remarks Must be called at IRQL == DISPATCH_LEVEL

Astyle for kernel code

astyle -b -c -y --style=ansi --mode=c $FILE

Text Editors

  • Notepad (GvG), problem is tab always == 8 spaces
  • Syn (w3seek), problem is tabs again
  • Eclipse (w3seek), like the same
  • Ultraedit on windows (hpoussin), indenting blank lines
  • vi on unix (tinus)
  • Crimson Editor (Ged) no known problems
  • VS 2k3 (Brandon), Don't know any problems. I like using tabs. Willing to change if need be.

See Also