qBittorrent/CODING_GUIDELINES.md
Vladimir Golovnev (Glassez) 59427ed6af Improve CODING_GUIDELINES.md.
2015-11-21 11:25:14 +03:00

4.7 KiB

All new code must follow the following coding guidelines.
If you make changes in a file that still uses another coding style, make sure that you follow these guidelines for your changes instead.
Note: I will now take your head if you forget and use another style. However, most probably the request will be delayed until you fix your coding style.

1. Curly braces

a. Function blocks, class/struct definitions, namespaces

int myFunction(int a)
{
    //code
}

void myFunction() {} // empty body

MyClass::MyClass(int *parent)
    : m_parent(parent)
{
    //initialize
}

int MyClass::myMethod(int a)
{
    //code
}

class MyOtherClass
{
public:
    //code
protected:
    //code
private:
    //code
};

namespace Name
{
    //code
}

// Lambdas
[](int arg1, int arg2) -> bool { return arg1 < arg2; }

[this](int arg)
{
    this->acc += arg;
}

b. Other code blocks

if (condition) {
    //code
}

for (int a = 0; a < b; ++b) {
    //code
}

switch (a) {
case 1:
    //blah
case 2:
    //blah
default:
    //blah
}

c. Blocks in switch's case labels

switch (var) {
case 1: {
        //declare local variables
        //code
    }
    break;
case 2: {
        //declare local variables
        //code
    }
    break;
default:
    //code
}

d. single-line blocks (lambdas, initializer lists etc.)

 {} // empty - space before {
 { body } // spaces around { and before }

2. If blocks

a. Multiple tests

if (condition) {
    //code
}
else if (condition) {
    //code
}
else {
    //code
}

The else if/else must be on their own lines.

b. Single statement if blocks

Most single statement if blocks should look like this:

if (condition)
    a = a + b;

One acceptable exception to this can be return, break or continue statements, provided that the test condition isn't very long. However you can choose to use the first rule instead.

a = myFunction();
b = a * 1500;

if (b > 0) return;
c = 100 / b;

c. Using curly braces for single statement if blocks

However, there are cases where curly braces for single statement if blocks should be used.

  • If some branch needs braces then all others should use them. Unless you have multiple else if in a row and the one needing the braces is only for a very small sub-block of code.
  • Another exception would be when we have nested if blocks or generally multiple levels of code that affect code readability.

Generally it will depend on the particular piece of code and would be determined on how readable that piece of code is. If in doubt always use braces if one of the above exceptions applies.

3. Indentation###

4 spaces.

4. File encoding and line endings.###

UTF-8 and Unix-like line ending (LF). Unless some platform specific files need other encodings/line endings.

5. Initialization lists.###

Initialization lists should be vertical. This will allow for more easily readable diffs. The initialization colon should be indented and in its own line along with first argument. The rest of the arguments should be indented too and have the comma prepended.

myClass::myClass(int a, int b, int c, int d)
    : m_a(a)
    , m_b(b)
    , m_c(c)
    , m_d(d)
{
    //code
}

6. Enums.###

Enums should be vertical. This will allow for more easily readable diffs. The members should be indented.

enum Days
{
    Monday,
    Tuesday,
    Wednesday,
    Thursday,
    Friday,
    Saturday,
    Sunday
};

7. Names.###

All names should be camelCased.

a. Type names and namespaces

Type names and namespaces start with Upper case letter (except POD types).

class ClassName {}

struct StructName {}

enum EnumName {}

typedef QList<ClassName> SomeList;

namespace NamespaceName
{
}

b. Variable names

Variable names start with lower case letter.

int myVar;

c. Private member variable names

Private member variable names start with lower case letter and should have m_ prefix.

class MyClass
{
    int m_myVar;
}

8. Misc.###

  • Line breaks for long lines with operation:
a += "b"
  + "c"
  + "d";
  • Space around operations eg a = b + c or a=b+c:

Before and after the assignment there should be a space. One exception could be: for loops.

for (int a=0; a<b; ++b) {
}
  • private/public/protected must not be indented

  • Preprocessor commands must go at line start

  • Method definitions aren't allowed in header files

###8. Not covered above### If something isn't covered above, just follow the same style the file you are editing has. If that particular detail isn't present in the file you are editing, then use whatever the rest of the project uses.