Coding Style

From ReactOS Wiki
Revision as of 20:48, 6 June 2006 by Fireball (talk | contribs)
Jump to: navigation, search

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

  • {} should be on its own line
  • When hacking on existing code follow the existing style rather than reformat
  • If reformatting to the generic coding style:
    • never mix code changes and formatting
    • say clear in commit message that you change formatting only (like [FORMATTING])
  • Don't reformat shared code (with Wine or other projects), it's hard to merge changes into reformatted code

The Rules

  • 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)
  • {} must be on its own line, they must be aligned to the beginning of previous statement, statements inside {} are indented
  • [NOT STRICT] Don't use {} if only one statement is enclosed in it (except when comments like /* TODO */ or /* FIXME */ or DPRINTs are included also)
  • [IN DISCUSSION] TABs should be used for indenting (using a good editor you can set TAB to any number of spaces you like - and people tend to like 2,3,4,8 - it's not possible to satisfy everyone's needs with a strict "put n spaces for indenting" rule).
  • Don't use TABs for formatting; use TABs for indenting only and use only spaces for formatting

Example: NTSTATUS SomeApi(IN Type Param1, [spaces]IN Type Param2) { [TAB]ULONG MyVar; [TAB]MyVar = 0; [TAB]if ((MyVar == 3) && [TAB][sp](Param1 == TRUE)) ...

  • Unfortunately if the code is shared with WINE, it isn't possible to use // comments, /*...*/ must always be used
  • 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
 SomeAPI( ...

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