Difference between revisions of "Coding Style"

From ReactOS Wiki
Jump to: navigation, search
(comments added)
(Added sample of API header by Filip)
Line 9: Line 9:
 
* 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)
 
* 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
 
* {} must be on its own line, they must be aligned to the beginning of previous statement, statements inside {} are indented
* Don't use {} if only one statement is enclosed in it (except when comments like //TODO or //FIXME or DPRINT are included also)
+
* Don't use {} if only one statement is enclosed in it (except when comments like /* TODO */ or /* FIXME */ or DPRINTs are included also)
 
* 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).
 
* 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).
* If comment is one line, please use //, if comment is multiline - use /* ... */
+
* Unfortunately if the code is shared with WINE, it isn't possible to use // comments, /*...*/ must always be used
 +
<nowiki>* Example of API header:
 +
/**
 +
  * @name SomeAPI
 +
  *
 +
  * 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 failure, STATUS_UNSUCCESSFUL
 +
  *        othwerwise.
 +
  */
 +
 
 +
NTSTATUS STDCALL
 +
SomeAPI( ...</nowiki>
  
 
Please also see [[Programming Guidelines]] section.
 
Please also see [[Programming Guidelines]] section.

Revision as of 18:08, 30 April 2005

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

Proposed rules (by Fireball, please feel free to critique them in irc or here)

  • 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
  • Don't use {} if only one statement is enclosed in it (except when comments like /* TODO */ or /* FIXME */ or DPRINTs are included also)
  • 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).
  • Unfortunately if the code is shared with WINE, it isn't possible to use // comments, /*...*/ must always be used

* Example of API header: /** * @name SomeAPI * * 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 failure, STATUS_UNSUCCESSFUL * othwerwise. */ NTSTATUS STDCALL SomeAPI( ...

Please also see Programming Guidelines section.