Skip to content
This repository has been archived by the owner on May 3, 2019. It is now read-only.

Coding guidelines

Colin Duquesnoy edited this page Jul 30, 2017 · 12 revisions

General Principles

We try to follow the below principles:

Code formatting

  • Always indent with 4 spaces
  • Always use UTF-8 encoding.
  • Put * and & by the variable rather than the type
// Good 
int* function(MyClass& myClass, int* result);

// Bad
void function(MyClass &myClass, int *result);
  • Put opening braces of namespaces, classes and functions at the beginning of the next line
// Good 
namespace MellowPlayer::Application
{
    class MyClass : public QObject
    { 
        Q_OBJECT
    public:
        int* function(MyClass& myClass, int* result)  
        {
            // Blabla
        }
    };
}
// Bad
namespace MellowPlayer::Application {
    class MyClass : public QObject { 
        Q_OBJECT
    public:
        void function(MyClass &myClass, int *result) {
            // Blabla
        }
    };
}
  • Put all other braces (if, switch, for, lambda,...) at the end of the line:
// Good 

int* function(MyClass& myClass, int* result)  
{
   if (foo) {
       for(auto& bar: myClass.bars()) {

       }
   }
   myClass->filter([&](QVariant& data) {
      qDebug() << data; 
   });
}

// Bad
void function(MyClass &myClass, int *result)
{
   if (foo) 
   {
       for(auto& bar: myClass.bars()) 
       {

       }
   }
}
  • When you derive from a base class, group any overriding functions in your header file together but don't use a labeled section/region. Use the override specifier on all these functions.
  • Avoid writing useless comments. If you need to write a comment, always ask yourself if it could be solved by extracting the block of code you want to comment to a new function with a descriptive name. Sometimes a comment is really necessary but most of the times you just need to split your long function into smaller function with very descriptive names.
  • Don't put formatting lines (-------------------------------------------) to separate regions, a blank line is more than enough.
  • Function declaration order should match function definition order.
  • Don't use else after return. So use:
  if (foo)
    return 1;
  return 2;

instead of:

  if (foo)
    return 1;
  else
    return 2;

Naming conventions

  • LCC = lowerCamelCase; UCC=UpperCamelCase *
  • Files and directories should use UCC, except for the root directories which must use lowercase.
  • Class names should use UCC
  • Namespaces should use UCC
  • Binaries should use UCC with the following format: MellowPlayer.LayerName, e.g.: MellowPlayer.Application.
  • Function and properties should use LCC. Setters should have a set prefix, don't use a get prefix for getters
  • Private/protected members use LCC with a _ suffix, e.g. myPrivateMember_

Namespaces

The base namespace is "MellowPlayer". Use a second namespace based on the layer where you add the code, e.g. MellowPlayer::Application, MellowPlayer::Infrastructure.

Always use nested namespaces declaration and indent the code under the namespace.

namespace MellowPlayer::Application 
{
   class Player
   {
        ...
   };
}

Headers

Don't use #ifdef include guards, use #pragma once.

Headers should be as clean as possible, don't clutter them with license headers, region delimiters and the likes.

Object ownership and calling conventions

Always prefer passing by reference instead of by pointer. Follow the boost::di semantics when you're dealing with automatically injected dependencies.