Difference between revisions of "Coding Style"

From ReactOS Wiki
Jump to: navigation, search
m
(Null, false and 0: string terminators)
(24 intermediate revisions by 9 users not shown)
Line 1: Line 1:
The ReactOS Project currently enforces very few rules for coding style.
+
This article describes general coding style guidelines, which should be used for new ReactOS code. These guidelines apply exclusively to C and C++ source files. The Members of ReactOS agreed on this document in the October 2013 meeting.
  
== Generic ideas whether and how to apply formatting ==
+
As much existing ReactOS code as possible should be converted to this style unless there are reasons against doing this (like if the code is going to be rewritten from scratch in the near future). See [[#Notes on reformatting existing code|Notes on reformatting existing code]] for more details.
  
* When hacking on existing code follow the existing style rather than reformat
+
Code synchronized with other sources (like Wine) must not be rewritten. [https://github.com/reactos/reactos/blob/master/media/doc/README.WINE README.WINE], [https://github.com/reactos/reactos/blob/master/media/doc/README.FSD README.FSD] and [https://github.com/reactos/reactos/blob/master/media/doc/3rd%20Party%20Files.txt 3rd Party Files.txt] files can be used for tracking synchronized files.
* 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
 
  
== Source code file structure ==
+
== File Structure ==
The usual source code file consists of the following parts (some sections can be omitted if they are empty):
+
<ol>
* The header (an example)
+
<li>Every ReactOS source code file should include a file header like this:
 
<syntaxhighlight lang="c">
 
<syntaxhighlight lang="c">
/*
+
/*
  * PROJECT:         ReactOS Kernel
+
* PROJECT:     ReactOS Kernel
  * LICENSE:         GPL - See COPYING in the top level directory
+
* LICENSE:     GPL-2.0-or-later (https://spdx.org/licenses/GPL-2.0-or-later)
  * FILE:           ntoskrnl/ob/namespce.c
+
* PURPOSE:     Does cool things like ...
  * PURPOSE:         Manages all functions related to the Object Manager name-
+
* COPYRIGHT:   Copyright 2017 Arno Nymous (abc@mailaddress.com)
  *                  space, such as finding objects or querying their names.
+
*             Copyright 2017 Mike Blablabla (mike@blabla.com)
  * PROGRAMMERS:     Alex Ionescu (alex.ionescu@reactos.org)
+
*/
  *                  Eric Kohl
 
  *                 Thomas Weidenmueller (w3seek@reactos.org)
 
  */
 
 
</syntaxhighlight>
 
</syntaxhighlight>
* Includes section, which has all #include statements, and vital defines (like #define NDEBUG)
+
 
 +
Please use SPDX license identifiers available at https://spdx.org/licenses.
 +
This makes our source file parseable by licensing tools!
 +
 
 +
You should add yourself to the <tt>COPYRIGHT</tt> section of a file if you did a major contribution to it and could take responsibility for the whole file or a part of it.
 +
 
 +
<tt>FILE</tt> line of the old header should be removed.
 +
</li>
 +
 
 +
<li>Use a header comparable to the following one for functions:
 +
<syntaxhighlight lang="c">
 +
/**
 +
* @brief Do nothing for 500ms.
 +
*
 +
* (optional) Description of what the function does. This part may refer to the parameters
 +
* of the function, like @p param1 or @p param2. A word of code can also be
 +
* inserted like @c this which is equivalent to <tt>this</tt> and can be useful
 +
* to say that the function returns a @c void or an @c int. If you want to have
 +
* more than one word in typewriter font, then just use @<tt@>.
 +
* Note the empty line before brief, it's important for splitting brief and detailed descriptions.
 +
*
 +
* @param[in] InputParameter
 +
* Description of the parameter.
 +
*
 +
* @param[out] OutputParameter
 +
* Description of the parameter.
 +
*
 +
* @param[in,out] InputOutputParameter
 +
* Description of the parameter.
 +
*
 +
* @param SomeParameter
 +
* Bleh, bleh :)
 +
*
 +
* @return
 +
* STATUS_SUCCESS in case of success, STATUS_UNSUCCESSFUL
 +
* otherwise.
 +
*
 +
* @see SomeOtherAPI
 +
*
 +
* @remarks Must be called at IRQL == DISPATCH_LEVEL
 +
*
 +
*/
 +
NTSTATUS
 +
SomeAPI(UINT32 InputParameter, UINT32 *OutputParameter, UINT32 *InputOutputParameter);
 +
</syntaxhighlight>
 +
[https://doxygen.reactos.org/ Doxygen] documentation generator is used for ReactOS codebase. Consider looking into it's [http://www.doxygen.nl/manual/commands.html manual] for the full list of the commands.</li>
 +
<li>For tagging a function as not implemented, use <code>@unimplemented</code> statement before <code>@brief</code></li>
 +
</ol>
 +
 
 +
== Indentation ==
 +
<ol>
 +
<li>Indent with 4 spaces, don’t use tabs!</li>
 +
<li><p>Indent both a case label and the case statement of a switch statement.</p>
 +
 
 +
'''Right:'''
 +
<syntaxhighlight lang="c">
 +
switch (Condition)
 +
{
 +
    case 1:
 +
        DoSomething();
 +
        break;
 +
}
 +
</syntaxhighlight>
 +
 
 +
'''Wrong:'''
 +
<syntaxhighlight lang="c">
 +
switch (Condition)
 +
{
 +
case 1:
 +
    DoSomething();
 +
    break;
 +
}
 +
</syntaxhighlight>
 +
</li>
 +
</ol>
 +
 
 +
== Spacing ==
 +
<ol>
 +
<li>Do not use spaces around unary operators.<br />
 +
'''Right:''' <code>i++;</code><br />
 +
'''Wrong:''' <code>i ++;</code>
 +
</li>
 +
 
 +
<li>Place spaces around binary and ternary operators.<br />
 +
'''Right:''' <code>a = b + c;</code><br />
 +
'''Wrong:''' <code>a=b+c;</code>
 +
</li>
 +
 
 +
<li><p>Do not place spaces before comma and semicolon.</p>
 +
 
 +
'''Right:'''
 +
<syntaxhighlight lang="c">
 +
for (int i = 0; i < 5; i++)
 +
    DoSomething();
 +
 
 +
func1(a, b);
 +
</syntaxhighlight>
 +
 
 +
'''Wrong:'''
 +
<syntaxhighlight lang="c">
 +
for (int i = 0 ; i < 5 ; i++)
 +
    DoSomething();
 +
 
 +
func1(a , b) ;
 +
</syntaxhighlight>
 +
</li>
 +
 
 +
<li><p>Place spaces between control statements and their parentheses.</p>
 +
 
 +
'''Right:'''
 +
<syntaxhighlight lang="c">
 +
if (Condition)
 +
    DoSomething();
 +
</syntaxhighlight>
 +
 
 +
'''Wrong:'''
 +
<syntaxhighlight lang="c">
 +
if(Condition)
 +
    DoSomething();
 +
</syntaxhighlight>
 +
</li>
 +
 
 +
<li><p>Do not place spaces between a function and its parentheses, or between a parenthesis and its content.</p>
 +
 
 +
'''Right:'''
 +
<syntaxhighlight lang="c">
 +
func(a, b);
 +
</syntaxhighlight>
 +
 
 +
'''Wrong:'''
 +
<syntaxhighlight lang="c">
 +
func (a, b);
 +
func( a, b );
 +
</syntaxhighlight>
 +
</li>
 +
</ol>
 +
 
 +
== Line breaking ==
 +
<ol>
 +
<li><p>Each statement should get its own line.</p>
 +
 
 +
'''Right:'''
 
<syntaxhighlight lang="c">
 
<syntaxhighlight lang="c">
/* INCLUDES ******************************************************************/
+
x++;
 +
y++;
 +
 
 +
if (Condition)
 +
    DoSomething();
 
</syntaxhighlight>
 
</syntaxhighlight>
* Defines section, for per-file defines
+
 
 +
'''Wrong:'''
 
<syntaxhighlight lang="c">
 
<syntaxhighlight lang="c">
/* DEFINES *******************************************************************/
+
x++; y++;
 +
 
 +
if (Condition) DoSomething();
 
</syntaxhighlight>
 
</syntaxhighlight>
* Private (not exported, or used only within the scope of this file) functions
+
</li>
 +
</ol>
 +
 
 +
== Braces ==
 +
<ol>
 +
<li>Always put braces (''{'' and ''}'') on their own lines.</li>
 +
<li><p>One-line control clauses may use braces, but this is not a requirement. An exception are one-line control clauses including additional comments.</p>
 +
 
 +
'''Right:'''
 
<syntaxhighlight lang="c">
 
<syntaxhighlight lang="c">
/* PRIVATE FUNCTIONS ******************************************************/
+
if (Condition)
 +
    DoSomething();
 +
 
 +
if (Condition)
 +
{
 +
    DoSomething();
 +
}
 +
 
 +
if (Condition)
 +
{
 +
    // This is a comment
 +
    DoSomething();
 +
}
 +
 
 +
if (Condition)
 +
    DoSomething();
 +
else
 +
    DoSomethingElse();
 +
 
 +
if (Condition)
 +
{
 +
    DoSomething();
 +
}
 +
else
 +
{
 +
    DoSomethingElse();
 +
    YetAnother();
 +
}
 
</syntaxhighlight>
 
</syntaxhighlight>
* Public functions (if it's a DLL, or a driver)
+
 
 +
'''Wrong:'''
 
<syntaxhighlight lang="c">
 
<syntaxhighlight lang="c">
/* PUBLIC FUNCTIONS **********************************************************/
+
if (Condition) {
 +
    DoSomething();
 +
}
 +
 
 +
if (Condition)
 +
    // This is a comment
 +
    DoSomething();
 +
 
 +
if (Condition)
 +
    DoSomething();
 +
else
 +
{
 +
    DoSomethingElse();
 +
    YetAnother();
 +
}
 
</syntaxhighlight>
 
</syntaxhighlight>
* Or just this way, if it's a standalone app
+
</li>
 +
</ol>
 +
 
 +
== Control structures ==
 +
<ol>
 +
<li>Don’t use inverse logic in control clauses.<br />
 +
'''Right:''' <code>if (i == 1)</code><br />
 +
'''Wrong:''' <code>if (1 == i)</code>
 +
</li>
 +
 
 +
<li><p>Avoid too many levels of cascaded control structures. Prefer a “linear style” over a “tree style”. Use <code>goto</code> when it helps to make the code cleaner (e.g. for cleanup paths).</p>
 +
 
 +
'''Right:'''
 
<syntaxhighlight lang="c">
 
<syntaxhighlight lang="c">
/* FUNCTIONS *****************************************************************/
+
if (!func1())
 +
    return;
 +
 
 +
i = func2();
 +
if (i == 0)
 +
    return;
 +
 
 +
j = func3();
 +
if (j == 1)
 +
    return;
 +
 
</syntaxhighlight>
 
</syntaxhighlight>
* [OPTIONAL?]File ends with
+
 
 +
'''Wrong:'''
 
<syntaxhighlight lang="c">
 
<syntaxhighlight lang="c">
/* EOF */<NewLineCharacterOnYourPlatform>
+
if (func1())
 +
{
 +
    i = func2();
 +
    if (func2())
 +
    {
 +
        j = func3();
 +
        if (func3())
 +
        {
 +
            …
 +
        }
 +
    }
 +
}
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
</li>
 +
</ol>
  
== The Rules ==  
+
== Naming ==
 +
<ol>
 +
<li><p>Capitalize names of variables and functions.<br />
 +
[[Hungarian Notation]] may be used when developing for Win32, but it is not required. If you don’t use it, the first letter of a name must be a capital too (no camelCase). Do not use underscores as separators either.</p>
  
* When a line with function call is less than 80 chars long, params should be written on the same line
+
'''Right:'''
* 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)
 
* TABs vs. Spaces:
 
** Kernel is strictly Spaces-only
 
** .rbuild files are strictly TABs-only
 
** When editing other modules, either obey the style, or do a conversion to one style (which results in fewer changes of tabs->spaces or vice versa).
 
* Generic note about TABs usage: Don't use TABs for formatting; use TABs for indenting only and use only spaces for formatting
 
Example:
 
 
<syntaxhighlight lang="c">
 
<syntaxhighlight lang="c">
NTSTATUS
+
PLIST_ENTRY FirstEntry;
SomeApi(IN Type Param1,
+
VOID NTAPI IopDeleteIoCompletion(PVOID ObjectBody);
[spaces]IN Type Param2)
+
PWSTR pwszTest;
{
 
[TAB]ULONG MyVar;
 
[TAB]MyVar = 0;
 
[TAB]if ((MyVar == 3) &&
 
[TAB][sp](Param1 == TRUE))
 
[TAB]{
 
[TAB][TAB]CallSomeFunc();
 
...
 
 
</syntaxhighlight>
 
</syntaxhighlight>
* 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:
+
'''Wrong:'''
  /*++
+
<syntaxhighlight lang="c">
  * @name SomeAPI
+
PLIST_ENTRY first_entry;
  * @implemented NT4
+
VOID NTAPI iop_delete_io_completion(PVOID objectBody);
  *
+
PWSTR pwsztest;
  * Do nothing for 500ms.
+
</syntaxhighlight>
  *
+
</li>
  * @param SomeParameter
+
 
  *        Description of the parameter. Wrapped to more lines on ~70th
+
<li>Avoid abbreviating function and variable names, use descriptive verbs where possible.</li>
  *        column.
+
<li><p>Precede boolean values with meaningful verbs like "is" and "did" if possible and if it fits the usage.</p>
  *
+
 
  * @param YetAnotherParameter
+
'''Right:'''
  *        Bleh, bleh :)
+
<syntaxhighlight lang="c">
  *
+
BOOLEAN IsValid;
  * @return STATUS_SUCCESS in case of success, STATUS_UNSUCCESSFUL
+
BOOLEAN DidSendData;
  *        othwerwise.
 
  *
 
  * @remarks Must be called at IRQL == DISPATCH_LEVEL
 
  *
 
  *--*/
 
  NTSTATUS
 
  STDCALL
 
  SomeAPI( ...
 
 
</syntaxhighlight>
 
</syntaxhighlight>
== Astyle for kernel code ==
 
  
astyle -b -c -y --style=ansi --mode=c $FILE
+
'''Wrong:'''
 +
<syntaxhighlight lang="c">
 +
BOOLEAN Valid;
 +
BOOLEAN SentData;
 +
</syntaxhighlight>
 +
</li>
 +
</ol>
  
== Text Editors ==
+
== Commenting ==
 +
<ol>
 +
<li><p>Avoid line-wasting comments, which could fit into a single line.</p>
  
* Notepad (GvG), problem is tab always == 8 spaces
+
'''Right:'''
* Syn (w3seek), problem is tabs again
+
<syntaxhighlight lang="c">
* Eclipse (w3seek), like the same
+
// This is a one-line comment
* 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 ==
+
/* This is a C-style comment */
* [[Programming Guidelines]]
+
 
 +
//
 +
// This is a comment over multiple lines.
 +
// We don’t define any strict rules for it.
 +
//
 +
</syntaxhighlight>
 +
 
 +
'''Wrong:'''
 +
<syntaxhighlight lang="c">
 +
//
 +
// This comment wastes two lines
 +
//
 +
</syntaxhighlight>
 +
</li>
 +
</ol>
 +
 
 +
== Null, false and 0 ==
 +
<ol>
 +
<li>The null pointer should be written as <code>NULL</code>.<br />
 +
In the rare case that your environment recommends a different null pointer (e.g. C++11 <code>nullptr</code>), you may use this one of course. Just don’t use the value <code>0</code>.</li>
 +
<li>Win32/NT Boolean values should be written as <code>TRUE</code> and <code>FALSE</code>.<br />
 +
In the rare case that you use C/C++ <code>bool</code> variables, you should write them as <code>true</code> and <code>false</code>.</li>
 +
<li>When you need to terminate ANSI or OEM string, or check for its terminator, use <code>ANSI_NULL</code>. If the string is Unicode or Wide string, use <code>UNICODE_NULL</code>.
 +
</ol>
 +
 
 +
== Notes on reformatting existing code ==
 +
* Never totally reformat a file and put a code change into it. Do this in separate commits.
 +
* If a commit only consists of formatting changes, say this clearly in the commit message by preceding it with ''[FORMATTING]''.
 +
 
 +
== Using an automatic code style tool ==
 +
TO BE ADDED BY [[User:Zefklop]]
 +
 
 +
== Points deliberately left out ==
 +
Additional ideas were suggested during the discussion of this document, but a consensus couldn't be reached on them. Therefore we refrain from enforcing any rules on these points:
 +
* TO BE ADDED BY [[User:Hbelusca]]
 +
 
 +
== See also ==
 +
* [[Kernel Coding Style]]
 
* [[GNU Indent]]
 
* [[GNU Indent]]
  
 
+
[[Category:Development]]
 
[[Category:Documentation]]
 
[[Category:Documentation]]
[[Category:Quality]]
+
[[Category:Tutorial]]

Revision as of 08:28, 8 June 2019

This article describes general coding style guidelines, which should be used for new ReactOS code. These guidelines apply exclusively to C and C++ source files. The Members of ReactOS agreed on this document in the October 2013 meeting.

As much existing ReactOS code as possible should be converted to this style unless there are reasons against doing this (like if the code is going to be rewritten from scratch in the near future). See Notes on reformatting existing code for more details.

Code synchronized with other sources (like Wine) must not be rewritten. README.WINE, README.FSD and 3rd Party Files.txt files can be used for tracking synchronized files.

File Structure

  1. Every ReactOS source code file should include a file header like this:
    /*
     * PROJECT:     ReactOS Kernel
     * LICENSE:     GPL-2.0-or-later (https://spdx.org/licenses/GPL-2.0-or-later)
     * PURPOSE:     Does cool things like ...
     * COPYRIGHT:   Copyright 2017 Arno Nymous (abc@mailaddress.com)
     *              Copyright 2017 Mike Blablabla (mike@blabla.com)
     */
    

    Please use SPDX license identifiers available at https://spdx.org/licenses. This makes our source file parseable by licensing tools!

    You should add yourself to the COPYRIGHT section of a file if you did a major contribution to it and could take responsibility for the whole file or a part of it.

    FILE line of the old header should be removed.

  2. Use a header comparable to the following one for functions:
    /**
     * @brief Do nothing for 500ms.
     *
     * (optional) Description of what the function does. This part may refer to the parameters
     * of the function, like @p param1 or @p param2. A word of code can also be
     * inserted like @c this which is equivalent to <tt>this</tt> and can be useful
     * to say that the function returns a @c void or an @c int. If you want to have
     * more than one word in typewriter font, then just use @<tt@>.
     * Note the empty line before brief, it's important for splitting brief and detailed descriptions.
     *
     * @param[in] InputParameter
     * Description of the parameter.
     *
     * @param[out] OutputParameter
     * Description of the parameter.
     *
     * @param[in,out] InputOutputParameter
     * Description of the parameter.
     *
     * @param SomeParameter
     * Bleh, bleh :)
     *
     * @return
     * STATUS_SUCCESS in case of success, STATUS_UNSUCCESSFUL
     * otherwise.
     *
     * @see SomeOtherAPI
     *
     * @remarks Must be called at IRQL == DISPATCH_LEVEL
     *
     */
    NTSTATUS
    SomeAPI(UINT32 InputParameter, UINT32 *OutputParameter, UINT32 *InputOutputParameter);
    
    Doxygen documentation generator is used for ReactOS codebase. Consider looking into it's manual for the full list of the commands.
  3. For tagging a function as not implemented, use @unimplemented statement before @brief

Indentation

  1. Indent with 4 spaces, don’t use tabs!
  2. Indent both a case label and the case statement of a switch statement.

    Right:

    switch (Condition)
    {
        case 1:
            DoSomething();
            break;
    }
    

    Wrong:

    switch (Condition)
    {
    case 1:
         DoSomething();
         break;
    }
    

Spacing

  1. Do not use spaces around unary operators.
    Right: i++;
    Wrong: i ++;
  2. Place spaces around binary and ternary operators.
    Right: a = b + c;
    Wrong: a=b+c;
  3. Do not place spaces before comma and semicolon.

    Right:

    for (int i = 0; i < 5; i++)
        DoSomething();
    
    func1(a, b);
    

    Wrong:

    for (int i = 0 ; i < 5 ; i++)
        DoSomething();
    
    func1(a , b) ;
    
  4. Place spaces between control statements and their parentheses.

    Right:

    if (Condition)
        DoSomething();
    

    Wrong:

    if(Condition)
        DoSomething();
    
  5. Do not place spaces between a function and its parentheses, or between a parenthesis and its content.

    Right:

    func(a, b);
    

    Wrong:

    func (a, b);
    func( a, b );
    

Line breaking

  1. Each statement should get its own line.

    Right:

    x++;
    y++;
    
    if (Condition)
        DoSomething();
    

    Wrong:

    x++; y++;
    
    if (Condition) DoSomething();
    

Braces

  1. Always put braces ({ and }) on their own lines.
  2. One-line control clauses may use braces, but this is not a requirement. An exception are one-line control clauses including additional comments.

    Right:

    if (Condition)
        DoSomething();
    
    if (Condition)
    {
        DoSomething();
    }
    
    if (Condition)
    {
        // This is a comment
        DoSomething();
    }
    
    if (Condition)
        DoSomething();
    else
        DoSomethingElse();
    
    if (Condition)
    {
        DoSomething();
    }
    else
    {
        DoSomethingElse();
        YetAnother();
    }
    

    Wrong:

    if (Condition) {
        DoSomething();
    }
    
    if (Condition)
        // This is a comment
        DoSomething();
    
    if (Condition)
        DoSomething();
    else
    {
        DoSomethingElse();
        YetAnother();
    }
    

Control structures

  1. Don’t use inverse logic in control clauses.
    Right: if (i == 1)
    Wrong: if (1 == i)
  2. Avoid too many levels of cascaded control structures. Prefer a “linear style” over a “tree style”. Use goto when it helps to make the code cleaner (e.g. for cleanup paths).

    Right:

    if (!func1())
        return;
    
    i = func2();
    if (i == 0)
        return;
    
    j = func3();
    if (j == 1)
        return;
    
    

    Wrong:

    if (func1())
    {
        i = func2();
        if (func2())
        {
            j = func3();
            if (func3())
            {
                
            }
        }
    }
    

Naming

  1. Capitalize names of variables and functions.
    Hungarian Notation may be used when developing for Win32, but it is not required. If you don’t use it, the first letter of a name must be a capital too (no camelCase). Do not use underscores as separators either.

    Right:

    PLIST_ENTRY FirstEntry;
    VOID NTAPI IopDeleteIoCompletion(PVOID ObjectBody);
    PWSTR pwszTest;
    

    Wrong:

    PLIST_ENTRY first_entry;
    VOID NTAPI iop_delete_io_completion(PVOID objectBody);
    PWSTR pwsztest;
    
  2. Avoid abbreviating function and variable names, use descriptive verbs where possible.
  3. Precede boolean values with meaningful verbs like "is" and "did" if possible and if it fits the usage.

    Right:

    BOOLEAN IsValid;
    BOOLEAN DidSendData;
    

    Wrong:

    BOOLEAN Valid;
    BOOLEAN SentData;
    

Commenting

  1. Avoid line-wasting comments, which could fit into a single line.

    Right:

    // This is a one-line comment
    
    /* This is a C-style comment */
    
    //
    // This is a comment over multiple lines.
    // We don’t define any strict rules for it.
    //
    

    Wrong:

    //
    // This comment wastes two lines
    //
    

Null, false and 0

  1. The null pointer should be written as NULL.
    In the rare case that your environment recommends a different null pointer (e.g. C++11 nullptr), you may use this one of course. Just don’t use the value 0.
  2. Win32/NT Boolean values should be written as TRUE and FALSE.
    In the rare case that you use C/C++ bool variables, you should write them as true and false.
  3. When you need to terminate ANSI or OEM string, or check for its terminator, use ANSI_NULL. If the string is Unicode or Wide string, use UNICODE_NULL.

Notes on reformatting existing code

  • Never totally reformat a file and put a code change into it. Do this in separate commits.
  • If a commit only consists of formatting changes, say this clearly in the commit message by preceding it with [FORMATTING].

Using an automatic code style tool

TO BE ADDED BY User:Zefklop

Points deliberately left out

Additional ideas were suggested during the discussion of this document, but a consensus couldn't be reached on them. Therefore we refrain from enforcing any rules on these points:

See also