Difference between revisions of "Code Style"

(Class declarations)
m (added Other Languages)
 
(16 intermediate revisions by 6 users not shown)
Line 5: Line 5:
 
Status: '''FALSE'''
 
Status: '''FALSE'''
  
When I encounter really pretty code in the open-source world (and the closed-source world for that matter), I'm a lot more confident that the software has real quality. Of course, from case to case, this may actually not be true, and the style might lie to me, but the important thing is that it ''appears'' to have high quality to people. On the other hand, if I encounter code which appear to be shit (although it might really be of excellent quality), it's tempting for me to try and find some alternative. So while enforcing code style might ''technically'' be a waste of time, it's psychologically. Also, if you ever intend to use LÖVE as a reference when applying for a job (I've done that), there is a slight chance they will take a ten second look on the code. Even if they are advanced enough to evaluate the code properly, they will not be immune to good (nor bad) style.
+
When I encounter really pretty code in the open-source world (and the closed-source world for that matter), I'm a lot more confident that the software has real quality. Of course, from case to case, this may actually not be true, and the style might lie to me, but the important thing is that it ''appears'' to have high quality to people. On the other hand, if I encounter code which appears to be shit (although it might really be of excellent quality), it's tempting for me to try and find some alternative. So while enforcing code style might ''technically'' be a waste of time, it's psychologically. Also, if you ever intend to use LÖVE as a reference when applying for a job (I've done that), there is a slight chance they will take a ten second look on the code. Even if they are advanced enough to evaluate the code properly, they will not be immune to good (nor bad) style.
  
 
'''Therefore''', because I'm such a fucking drone, I'm going to refactor some code here and there (or everywhere) to make things more beautiful. And since I'm potentially fucking up everything anyway, I thought we could decide on a coding style that the majority likes. It's unlikely that we all agree on everything ... but hopefully everyone will accept the decision of the majority.
 
'''Therefore''', because I'm such a fucking drone, I'm going to refactor some code here and there (or everywhere) to make things more beautiful. And since I'm potentially fucking up everything anyway, I thought we could decide on a coding style that the majority likes. It's unlikely that we all agree on everything ... but hopefully everyone will accept the decision of the majority.
Line 11: Line 11:
 
== Namespaces ==
 
== Namespaces ==
  
'''Any number of namespaces indent just one level.'''
+
'''Namespace bodies are not indented.'''
  
  '''YES:'''
+
'''YES:'''
 +
<source lang="cpp">
 +
namespace love
 +
{
 +
namespace graphics
 +
{
  
   namespace love
+
class Foo
  {
+
{
 +
public:
 +
   /* ... */
 +
};
 +
 
 +
} // graphics
 +
} // love
 +
</source>
 +
 
 +
'''NO:'''
 +
<source lang="cpp"> 
 +
namespace love
 +
{
 
   namespace graphics
 
   namespace graphics
 
   {
 
   {
 +
 
       class Foo
 
       class Foo
 
       {
 
       {
 +
      public:
 +
          /* ... */
 
       };
 
       };
 +
 
   } // graphics
 
   } // graphics
  } // love
+
} // love
 
+
</source>
  '''NO:'''
 
 
 
  namespace love
 
  {
 
      namespace graphics
 
      {
 
          class Foo
 
          {
 
          };
 
      } // graphics
 
  } // love
 
  
 
== Class declarations ==
 
== Class declarations ==
Line 41: Line 51:
 
'''Should have a capital first letter.'''
 
'''Should have a capital first letter.'''
  
  '''YES:'''
+
'''YES:'''
 +
<source lang="cpp">
 +
class Foo
 +
{
 +
};
 +
</source>
  
  class Foo
+
'''NO:'''
  {
+
<source lang="cpp">
  };
+
class foo
 +
{
 +
};
  
  '''NO:'''
+
class FOO
 
+
{
  class foo
+
};
  {
+
</source>
  };
 
 
 
  class FOO
 
  {
 
  };
 
  
 
'''Visiblity blocks should be in decreasing order.'''
 
'''Visiblity blocks should be in decreasing order.'''
Line 61: Line 73:
 
It makes sense to have the visible "API" first. This is what a reader will normally want to know first anyway.
 
It makes sense to have the visible "API" first. This is what a reader will normally want to know first anyway.
  
  '''YES:'''
+
'''YES:'''
 +
<source lang="cpp">
 +
class Foo
 +
{
 +
public:
 +
protected:
 +
private:
 +
};
 +
</source>
  
  class Foo
+
'''NO:'''
  {
+
<source lang="cpp">
  public:
+
class Foo
  protected:
+
{
  private:
+
private:
  };
+
protected:
 
+
public:
  '''NO:'''
+
};
 
+
</source>
  class Foo
 
  {
 
  private:
 
  protected:
 
  public:
 
  };
 
  
 
'''For multiple inheritance, each class should appear on its own line.'''
 
'''For multiple inheritance, each class should appear on its own line.'''
Line 83: Line 97:
 
Each line should ''start'' with the colon or comma. My experience is that this is the most flexible style with respect to diffs and #ifdeffery.
 
Each line should ''start'' with the colon or comma. My experience is that this is the most flexible style with respect to diffs and #ifdeffery.
  
  '''YES:'''
+
'''YES:'''
+
<source lang="cpp">
  class Foo : public Bar
+
class Foo : public Bar
  {
+
{
  };
+
};
  
  class Foo
+
class Foo
      : public Bar
+
  : public Bar
      , public Foz
+
  , public Foz
  {
+
{
  };
+
};
 +
</source>
  
  '''NO:'''
+
'''NO:'''
+
<source lang="cpp">
  class Foo : public Bar, public Foz
+
class Foo : public Bar, public Foz
  {
+
{
  };
+
};
 +
</source>
  
 
== Initializer lists ==
 
== Initializer lists ==
  
 
'''Like inheritance lists, each initialization on its own line.'''
 
'''Like inheritance lists, each initialization on its own line.'''
 
  '''YES:'''
 
 
  Foo::Foo()
 
      : bar(0)
 
      , foo(1)
 
  {
 
  }
 
  
  '''NO:'''
+
'''YES:'''
 +
<source lang="cpp">
 +
Foo::Foo()
 +
  : bar(0)
 +
  , foo(1)
 +
{
 +
}
 +
</source>
  
  Foo::Foo() : bar(0) , foo(1)
+
'''NO:'''
  {
+
<source lang="cpp">
  }
+
Foo::Foo() : bar(0) , foo(1)
 +
{
 +
}
 +
</source>
  
 
== Functions/methods ==
 
== Functions/methods ==
Line 123: Line 141:
 
'''Functions and methods should use camelCase.'''
 
'''Functions and methods should use camelCase.'''
  
  '''YES:'''
+
'''YES:'''
 
+
<source lang="cpp">
  int doomFist(int where);
+
int doomFist(int where);
 
+
</source>
  '''NO:'''
 
  
  int DoomFist(int where);
+
'''NO:'''
  int doom_fist(int where);
+
<source lang="cpp">
 +
int DoomFist(int where);
 +
int doom_fist(int where);
 +
</source>
  
 
'''Parentheses should appear directly after the name, with no space in between.'''
 
'''Parentheses should appear directly after the name, with no space in between.'''
  
  '''YES:'''
+
'''YES:'''
 +
<source lang="cpp">
 +
int doomFist(int where);
 +
</source>
  
  int doomFist(int where);
+
'''NO:'''
 
+
<source lang="cpp">
  '''NO:'''
+
int doomFist (int where);
 
+
</source>
  int doomFist (int where);
 
 
    
 
    
 
'''There must be no unnecessary space immediately after the open-paren and immediately before the close-paren.'''
 
'''There must be no unnecessary space immediately after the open-paren and immediately before the close-paren.'''
  
  '''YES:'''
+
'''YES:'''
 +
<source lang="cpp">
 +
int doomFist(int where);
 +
</source>
  
  int doomFist(int where);
+
'''NO:'''
 +
<source lang="cpp">
 +
int doomFist( int where );
 +
</source>
  
  '''NO:'''
+
'''One-liners like getters and setters can be inlined in the class declaration. (More-than-one-liners should however not be inlined).'''
  
   int doomFist( int where );
+
'''RECOMMENDED:'''
 +
<source lang="cpp">
 +
class Foo
 +
{
 +
public:
 +
  void setBar(int bar) { this->bar = bar; }
 +
   int getBar() const { return bar; }
 +
private:
 +
  int bar;
 +
};
 +
</source>
  
'''One-liners like getters and setters can be inlined in the class declaration. (More-than-one-liners should however not be inlined).'''
+
'''DISCOURAGED:'''
 +
<source lang="cpp">
 +
class Foo
 +
{
 +
public:
 +
  void setBar(int bar);
 +
  int getBar() const;
 +
private:
 +
  int bar;
 +
};
 +
 
 +
void Foo::setBar(int bar)
 +
{
 +
  this->bar = bar;
 +
}
  
   '''RECOMMENDED:'''
+
int Foo::getBar() const
 +
{
 +
   return bar;
 +
}
 +
</source>
  
  class Foo
+
== Control blocks ==
  {
 
  public:
 
      void setBar(int bar) { this->bar = bar; }
 
      int getBar() const { return bar; }
 
  private:
 
      int bar;
 
  };
 
  
  '''DISCOURAGED:'''
+
'''Control blocks should have a space between the keyword the parenthesized''' expression. This differentiates control statements visually from function calls.
  
  class Foo
+
'''YES:'''
  {
+
<source lang="cpp">
  public:
+
if (foo)
      void setBar(int bar);
+
   /* ... */;
      int getBar() const;
+
</source>
   private:
 
      int bar;
 
  };
 
  
  void Foo::setBar(int bar)
+
'''NO:'''
   {
+
<source lang="cpp">
      return this->bar = bar;
+
if(foo)
  }
+
   /* ... */;
 +
</source>
  
  int Foo::getBar() const
+
'''Braces should normally be omitted if they can. (Saves vertical space).'''
  {
 
      return bar;
 
  }
 
  
== Control blocks ==
+
'''YES:'''
 +
<source lang="cpp">
 +
if (foo)
 +
  bar();
 +
</source>
  
'''Control blocks should have a space between the keyword the parenthesized''' expression. This differentiates control statements visually from function calls.
+
'''NO:'''
 +
<source lang="cpp">
 +
if (foo)
 +
{
 +
  bar();
 +
}
 +
</source>
  
  '''YES:'''
+
'''YES:'''
+
<source lang="cpp">
  if (foo)
+
if (foo)
      /* ... */;
+
  bar();
 +
else
 +
{
 +
  foz();
 +
  baz();
 +
}
 +
</source>
  
  '''NO:'''
+
'''NO:'''
 +
<source lang="cpp">
 +
if (foo)
 +
{
 +
  bar();
 +
}
 +
else
 +
{
 +
  foz();
 +
  baz();
 +
}
 +
</source>
  
  if(foo)
+
'''Braces should appear on the next line.'''
      /* ... */;
 
  
'''Braces should normally be omitted if they can. (Saves vertical space).'''
+
'''YES:'''
 +
<source lang="cpp">
 +
if (foo)
 +
{
 +
  bar1();
 +
  bar2();
 +
}
 +
</source>
  
  '''YES:'''
+
'''NO:'''
+
<source lang="cpp">
  if (foo)
+
if (foo) {
      bar();
+
  bar1();
 +
  bar2();
 +
}
 +
</source>
  
  '''NO:'''
+
== Switch-case ==
  
  if (foo)
+
'''case keyword should be on same level as the braces for the switch keyword.'''
  {
 
      bar();
 
  }
 
  
'''Braces should appear on the next line.'''
+
'''YES:'''
 +
<source lang="cpp">
 +
switch (foo)
 +
{
 +
case 1:
 +
    // do stuff
 +
    break;
 +
case 2:
 +
    // do another stuff
 +
    break;
 +
default:
 +
    break;
 +
}
 +
</source>
  
  '''YES:'''
+
'''NO:'''
 +
<source lang="cpp">
 +
switch (foo)
 +
{
 +
    case 1:
 +
        // do stuff
 +
        break;
 +
    case 2:
 +
        // do another stuff
 +
        break;
 +
    default:
 +
        break;
 +
}
 +
</source>
  
  if (foo)
+
'''If case codeblock must be enclosed with braces, the braces goes on same level as the case keyword itself.'''
  {
 
      bar1();
 
      bar2();
 
  }
 
  
  '''NO:'''
+
<source lang="cpp">
 
+
switch (foo)
  if (foo) {
+
{
      bar1();
+
case 1:
      bar2();
+
{
  }
+
    // do
 +
    // something
 +
    // with
 +
    // this big
 +
    // code
 +
    break;
 +
}
 +
case 2:
 +
    // do simpler stuff
 +
    break;
 +
default:
 +
    break;
 +
}
 +
</source>
  
 
== Pointer affinity ==
 
== Pointer affinity ==
Line 237: Line 349:
 
This makes it consistent with dereferencing (*foo), and is preferred by most LÖVE devs.
 
This makes it consistent with dereferencing (*foo), and is preferred by most LÖVE devs.
  
'''YES:'''
+
'''YES:'''
+
<source lang="cpp">
int *foo;
+
int *foo;
int &bar;
+
int &bar;
 +
</source>
  
'''NO:'''
+
'''NO:'''
+
<source lang="cpp">
int* foo;
+
int* foo;
int& bar;
+
int& bar;
 
int * foo;
 
int & bar;
 
  
'''YES:'''
+
int * foo;
+
int & bar;
int *get_int_ptr();
+
</source>
int &get_int_ref();
 
 
'''NO:'''
 
  
int* get_int_ptr();
+
'''YES:'''
int& get_int_ref();
+
<source lang="cpp">
 +
int *get_int_ptr();
 +
int &get_int_ref();
 +
</source>
  
int * get_int_ptr();
+
'''NO:'''
int & get_int_ref();
+
<source lang="cpp">
 +
int* get_int_ptr();
 +
int& get_int_ref();
 +
 
 +
int * get_int_ptr();
 +
int & get_int_ref();
 +
</source>
  
 
== Spaces vs Tabs ==
 
== Spaces vs Tabs ==
  
 
I personally prefer tabs, but I know I'm the only person in the world. We will probably end up with spaces, in which case I suggest 4 spaces per level.
 
I personally prefer tabs, but I know I'm the only person in the world. We will probably end up with spaces, in which case I suggest 4 spaces per level.
 +
 +
EDIT: I was wrong, everyone (who has so far given a damn) has preferred tabs. In that case, let me specify a more advanced indentation guideline for the truly l33t, hardcore, and handsome.
 +
 +
MIXED TABS AND SPACES (*monocle pops*)
 +
 +
'''Use tabs for normal indentation.'''
 +
 +
I.e. when indicating scope.
 +
 +
'''YES:'''
 +
<source lang="cpp">
 +
if (foo)
 +
{
 +
<tab>bar();
 +
}
 +
</source>
 +
 +
'''NO:'''
 +
<source lang="cpp">
 +
if (foo)
 +
{
 +
<space><space><space><space>bar();
 +
}
 +
</source>
 +
 +
'''Use spaces for alignment.'''
 +
 +
If you ''really'' want to align stuff, then the important thing to keep in mind is that the alignment should not break if the viewer is using a tab-size that's different from yours. So, in this example, we're aligning stuff:
 +
<source lang="cpp">
 +
if (foo)
 +
{
 +
    int a_var      = 1;
 +
    int anoter_var = 2;
 +
    int moar      = 3;
 +
    int doom      = 4;
 +
}
 +
</source>
 +
 +
'''YES:'''
 +
<source lang="cpp">
 +
if (foo)
 +
{
 +
<tab>int a_var<space * 6>= 1;
 +
<tab>int anoter_var<space>= 2;
 +
<tab>int moar<space * 7>= 3;
 +
<tab>int doom<space * 7>= 4;
 +
}
 +
</source>
 +
 +
'''NO:'''
 +
<source lang="cpp">
 +
if (foo)
 +
{
 +
<tab>int a_var<tab * 2>= 1;
 +
<tab>int anoter_var<tab>= 2;
 +
<tab>int moar<tab * 2>= 3;
 +
<tab>int doom<tab * 2>= 4;
 +
}
 +
</source>
 +
 +
However, use alignment sparingly, because it makes a lot of diff noise when you add something that's longer than the currently longest thing, and you have to realign everything. So the best option is actually:
 +
 +
== Trailing whitespace ==
 +
 +
'''Trim all trailing whitespace.'''
 +
 +
Tabs and spaces before a newline character increase the noise in commits and the source code.
 +
 +
'''YES:'''
 +
<source lang="cpp">
 +
<tab>foo();
 +
 +
<tab>bar();
 +
</source>
 +
 +
'''NO:'''
 +
<source lang="cpp">
 +
<tab>foo();
 +
<tab>
 +
<tab>bar();
 +
</source>
  
 
== Documentation blocks ==
 
== Documentation blocks ==
  
* Align the asterisks vertically.
+
'''Asterisks should be aligned vertically.'''
 +
 
 +
'''YES:'''
 +
<source lang="cpp">
 +
/**
 +
* Short description.
 +
*
 +
* @param foo The foo that goes in the bar.
 +
* @param bar The bar the foo foes into.
 +
*/
 +
int foz(int foo, int &bar);
 +
</source>
 +
 
 +
'''NO:'''
 +
<source lang="cpp">
 +
/**
 +
* Short description.
 +
*
 +
* @param foo The foo that goes in the bar.
 +
* @param bar The bar the foo foes into.
 +
*/
 +
int foz(int foo, int &bar);
 +
</source>
 +
 
 +
 
 +
If you agree to this, and you also agree that we're using tabs. You're agreeing that tabs and spaces be mixed (although in a very defined way). For a function declaration that's indented one block, you would type something like:
  
'''YES:'''
+
   <tab>/**
+
  <tab><space>* Short description.
   /**
+
   <tab><space>*
  * Short description.
+
   <tab><space>* Long description.
  *
+
   <tab><space>*/
  * @param foo The foo that goes in the bar.
 
  * @param bar The bar the foo foes into.
 
  */
 
   int foz(int foo, int& bar);
 
 
'''NO:'''
 
 
  /**
 
   * Short description.
 
   *
 
  * @param foo The foo that goes in the bar.
 
  * @param bar The bar the foo foes into.
 
  */
 
  int foz(int foo, int& bar);
 
  
 
== #includes ==
 
== #includes ==
  
* Non-system includes should use the double-quotes syntax.
+
'''Non-system includes should use the double-quotes syntax.'''
 +
 
 +
'''YES:'''
 +
<source lang="cpp">
 +
#include "common/config.h"
 +
</source>
 +
 
 +
'''NO:'''
 +
<source lang="cpp">
 +
#include <common/config.h>
 +
</source>
 +
 
 +
== Casts ==
 +
 
 +
'''Use C-style casts.'''
 +
 
 +
Remember to also Know What You Are Doing when using C-style casts.
 +
 
 +
'''YES:'''
 +
<source lang="cpp">
 +
Foo *foo = (Foo *) bar;
 +
</source>
 +
 
 +
'''NO:'''
 +
<source lang="cpp">
 +
Foo *foo = (Foo*)bar;
 +
Foo *foo = (Foo*) bar;
 +
Foo *foo = (Foo *)bar;
 +
</source>
 +
 
 +
== Writing null ==
  
'''YES:'''
+
'''Prefer nullptr over NULL or 0.'''
  
#include "common/config.h"
+
'''YES:'''
 +
<source lang="cpp">
 +
foo = nullptr;
 +
bar = nullptr;
 +
</source>
  
'''NO:'''
+
'''NO:'''
 +
<source lang="cpp">
 +
foo = NULL;
 +
bar = 0;
 +
</source>
  
#include <common/config.h>
+
== Other Languages ==
 +
{{i18n|Code Style}}

Latest revision as of 01:15, 8 July 2023

Introduction

"Every second spent enforcing code style is a waste of time". -- Someone, at some point

Status: FALSE

When I encounter really pretty code in the open-source world (and the closed-source world for that matter), I'm a lot more confident that the software has real quality. Of course, from case to case, this may actually not be true, and the style might lie to me, but the important thing is that it appears to have high quality to people. On the other hand, if I encounter code which appears to be shit (although it might really be of excellent quality), it's tempting for me to try and find some alternative. So while enforcing code style might technically be a waste of time, it's psychologically. Also, if you ever intend to use LÖVE as a reference when applying for a job (I've done that), there is a slight chance they will take a ten second look on the code. Even if they are advanced enough to evaluate the code properly, they will not be immune to good (nor bad) style.

Therefore, because I'm such a fucking drone, I'm going to refactor some code here and there (or everywhere) to make things more beautiful. And since I'm potentially fucking up everything anyway, I thought we could decide on a coding style that the majority likes. It's unlikely that we all agree on everything ... but hopefully everyone will accept the decision of the majority.

Namespaces

Namespace bodies are not indented.

YES:

namespace love
{
namespace graphics
{

class Foo
{
public:
  /* ... */
};

} // graphics
} // love

NO:

  
namespace love
{
  namespace graphics
  {

      class Foo
      {
      public:
          /* ... */
      };

  } // graphics
} // love

Class declarations

Should have a capital first letter.

YES:

class Foo
{
};

NO:

class foo
{
};

class FOO
{
};

Visiblity blocks should be in decreasing order.

It makes sense to have the visible "API" first. This is what a reader will normally want to know first anyway.

YES:

class Foo
{
public:
protected:
private:
};

NO:

class Foo
{
private:
protected:
public:
};

For multiple inheritance, each class should appear on its own line.

Each line should start with the colon or comma. My experience is that this is the most flexible style with respect to diffs and #ifdeffery.

YES:

class Foo : public Bar
{
};

class Foo
  : public Bar
  , public Foz
{
};

NO:

class Foo : public Bar, public Foz
{
};

Initializer lists

Like inheritance lists, each initialization on its own line.

YES:

Foo::Foo()
  : bar(0)
  , foo(1)
{
}

NO:

Foo::Foo() : bar(0) , foo(1)
{
}

Functions/methods

Functions and methods should use camelCase.

YES:

int doomFist(int where);

NO:

int DoomFist(int where);
int doom_fist(int where);

Parentheses should appear directly after the name, with no space in between.

YES:

int doomFist(int where);

NO:

int doomFist (int where);

There must be no unnecessary space immediately after the open-paren and immediately before the close-paren.

YES:

int doomFist(int where);

NO:

int doomFist( int where );

One-liners like getters and setters can be inlined in the class declaration. (More-than-one-liners should however not be inlined).

RECOMMENDED:

class Foo
{
public:
  void setBar(int bar) { this->bar = bar; }
  int getBar() const { return bar; }
private:
  int bar;
};

DISCOURAGED:

class Foo
{
public:
  void setBar(int bar);
  int getBar() const;
private:
  int bar;
};

void Foo::setBar(int bar)
{
  this->bar = bar;
}

int Foo::getBar() const
{
  return bar;
}

Control blocks

Control blocks should have a space between the keyword the parenthesized expression. This differentiates control statements visually from function calls.

YES:

if (foo)
  /* ... */;

NO:

if(foo)
  /* ... */;

Braces should normally be omitted if they can. (Saves vertical space).

YES:

if (foo)
  bar();

NO:

if (foo)
{
  bar();
}

YES:

if (foo)
  bar();
else
{
  foz();
  baz();
}

NO:

if (foo)
{
  bar();
}
else
{
  foz();
  baz();
}

Braces should appear on the next line.

YES:

if (foo)
{
  bar1();
  bar2();
}

NO:

if (foo) {
  bar1();
  bar2();
}

Switch-case

case keyword should be on same level as the braces for the switch keyword.

YES:

switch (foo)
{
case 1:
    // do stuff
    break;
case 2:
    // do another stuff
    break;
default:
    break;
}

NO:

switch (foo)
{
    case 1:
        // do stuff
        break;
    case 2:
        // do another stuff
        break;
    default:
        break;
}

If case codeblock must be enclosed with braces, the braces goes on same level as the case keyword itself.

switch (foo)
{
case 1:
{
    // do
    // something
    // with
    // this big
    // code
    break;
}
case 2:
    // do simpler stuff
    break;
default:
    break;
}

Pointer affinity

For pointers and references, the asterisk/ampersand should appear next to the variable name.

This makes it consistent with dereferencing (*foo), and is preferred by most LÖVE devs.

YES:

int *foo;
int &bar;

NO:

int* foo;
int& bar;

int * foo;
int & bar;

YES:

int *get_int_ptr();
int &get_int_ref();

NO:

int* get_int_ptr();
int& get_int_ref();

int * get_int_ptr();
int & get_int_ref();

Spaces vs Tabs

I personally prefer tabs, but I know I'm the only person in the world. We will probably end up with spaces, in which case I suggest 4 spaces per level.

EDIT: I was wrong, everyone (who has so far given a damn) has preferred tabs. In that case, let me specify a more advanced indentation guideline for the truly l33t, hardcore, and handsome.

MIXED TABS AND SPACES (*monocle pops*)

Use tabs for normal indentation.

I.e. when indicating scope.

YES:

if (foo)
{
<tab>bar();
}

NO:

if (foo)
{
<space><space><space><space>bar();
}

Use spaces for alignment.

If you really want to align stuff, then the important thing to keep in mind is that the alignment should not break if the viewer is using a tab-size that's different from yours. So, in this example, we're aligning stuff:

if (foo)
{
    int a_var      = 1;
    int anoter_var = 2;
    int moar       = 3;
    int doom       = 4;
}

YES:

if (foo)
{
<tab>int a_var<space * 6>= 1;
<tab>int anoter_var<space>= 2;
<tab>int moar<space * 7>= 3;
<tab>int doom<space * 7>= 4;
}

NO:

if (foo)
{
<tab>int a_var<tab * 2>= 1;
<tab>int anoter_var<tab>= 2;
<tab>int moar<tab * 2>= 3;
<tab>int doom<tab * 2>= 4;
}

However, use alignment sparingly, because it makes a lot of diff noise when you add something that's longer than the currently longest thing, and you have to realign everything. So the best option is actually:

Trailing whitespace

Trim all trailing whitespace.

Tabs and spaces before a newline character increase the noise in commits and the source code.

YES:

<tab>foo();

<tab>bar();

NO:

<tab>foo();
<tab>
<tab>bar();

Documentation blocks

Asterisks should be aligned vertically.

YES:

/**
 * Short description.
 *
 * @param foo The foo that goes in the bar.
 * @param bar The bar the foo foes into.
 */
int foz(int foo, int &bar);

NO:

/**
* Short description.
*
* @param foo The foo that goes in the bar.
* @param bar The bar the foo foes into.
*/
int foz(int foo, int &bar);


If you agree to this, and you also agree that we're using tabs. You're agreeing that tabs and spaces be mixed (although in a very defined way). For a function declaration that's indented one block, you would type something like:

 <tab>/**
 <tab><space>* Short description.
 <tab><space>*
 <tab><space>* Long description.
 <tab><space>*/

#includes

Non-system includes should use the double-quotes syntax.

YES:

#include "common/config.h"

NO:

#include <common/config.h>

Casts

Use C-style casts.

Remember to also Know What You Are Doing when using C-style casts.

YES:

Foo *foo = (Foo *) bar;

NO:

Foo *foo = (Foo*)bar;
Foo *foo = (Foo*) bar;
Foo *foo = (Foo *)bar;

Writing null

Prefer nullptr over NULL or 0.

YES:

foo = nullptr;
bar = nullptr;

NO:

foo = NULL;
bar = 0;

Other Languages