CONTRIBUTING.md

ringwormGO coding style

Does not apply if repository has own coding style

How to start contributing

Just drop a Pull Request :)

Coding style

1. Use LF instead of CRLF
2. Use spaces, size 4.

Please run make production before pushing code

Indentation and line width

1. 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;
}

When a function call does not fit onto a line, align arguments like this:

FunctionCall(arg1,
             arg2,
             arg3);

When making new functions, use an return type. Right:

int func() {}

Wrong:

func() {}

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 (except for curly parentheses), or between a parenthesis and its content.

Right:

func(a, b);
return { a, b };

Wrong:

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

return {a, b};

Line breaking

1. Each statement should get its own line.

Right:

x++;
y++;

if (Condition)
{
    DoSomething();
}

Also right but don't use it often

if (Condition) DoSomething(); 

if (Condition)
    DoSomething();

Wrong:

x++; y++;

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

Naming functions

1. Function names are lowercase letters.

Right: void func();

Wrong: void Func();

Naming structs, classes, unions and variables

2. Name a struct, class, union etc. with cappital letter and variable which lowercase letter

Right:

struct Test
{
  int number;
}

Test test;

Wrong:

struct test
{
  int Number;
}

test Test;

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
//

Other points

1. Do not use LARGE_INTEGER/ULARGE_INTEGER unless needed for using APIs. Use int64/uint64 instead
2. Use #pragma once instead of guard defines in headers

Used resources:

• https://reactos.org/wiki/Coding_Style