Coding Conventions

Everybody has their own preferred style for writing code, however, in the interest of making the codebase easier to maintain, we request that the following conventions be observed. Code that is lifted from other projects does not need to be modified to match these rules – no need to fix what isn't broken.

This convention page follows the requirements keywords of RFC 2119. Requirements are seen as CAPITAL letter words.

The majority of LMMS conventions follows the Qt Coding Style. Some conventions are repeated here, and if not noted here MAY fall under the Qt style.

Header Files and Include Statements

Header Guards

Header guards CANT begin with an underscore _. Identifiers that begin with an underscore + CAPITAL letter are reserved identifiers in C++. If you edit an older file which contains an improper header guard, please fix it to comply with guidelines.

Include Order

The first #include in a cpp file MUST be its own related header file. Afterwards group #includes by type, where groups are separated by a newline, and ordered by name.

// MySourceFile.cpp
#include "MySourceFile.h"

#include <QMap>
#include <QString>

#include "DataFile.h"
#include "Engine.h"
#include "GuiApplication.h"

Naming

Type Names

Types MUST begin with an uppercase letter.

class ResourcesDB;
enum MyEnum
{
...
};
typedef QList<AutomatableModel *> AutoModelList;

Variable Names

Variables MUST use camel case format, for example: nextValue.

Class Members

1. Non-static member variables MUST be prefixed with m_
2. Static variables MUST be prefixed with s_

The remaining variable name MUST follow the Variable Names rule.

float m_currentValue;
static int s_quantization;

Function Parameters

Some older code prefixed function parameters with an underscore _. Function parameters SHOULD NEVER be prefixed with an underscore.

Formatting

Line Length

Every line of text SHOULD be at most 120 characters long.

Indentation

Tabs MUST be used for indentation. Instructions for configuring QtCreator can be found here.

Flow Control Statements

Flow control statements (if, else if, else, for, do, while, and switch) MUST have a space between the keyword and the opening parenthesis.

True/False

You MUST use the true/false keywords instead of non-standard macros.

b = TRUE; // BAD
b = true; // GOOD
b = 1; // BAD

Ternary Operator

The ternary operator ? : SHOULD ONLY be used when it makes the code more readable or streamlined.

Whitespace

Braces

1. Spaces CANT be added after an opening brace
2. Spaces CANT be added before a closing brace
3. Flow control statements (if, else if, else, for, do, while, and switch) MUST use explicit blocking
4. Block brackets SHOULD be on their own line

// Spaces before/after brackets
void doThis( int a ); // BAD
void doThis(int a); // GOOD
if ( m_sample > 0 ) // BAD
if (m_sample > 0) // GOOD
array[ offset ] // BAD
array[offset] // GOOD

// BAD - Example of not explicit blocking
if (m_sample > 0)
	--m_sample;
// GOOD - Example of explicit blocking
if (m_sample > 0)
{
	--m_sample;
}
// If the block can fit on one line, it is acceptable to format it as below
if (m_sample > 0) { --m_sample; }

Return Statements

Return statements CANT have parenthesis around the returned value.

return (bar); // BAD
return bar; // GOOD

Semicolons

Spaces CANT be added before semicolons.

return this ; // BAD
return this; // GOOD

Infix Operators

Spaces MUST be before and after infix operators (=, +, -, *, /, etc.).

sub_note_key_base=base_note_key+octave_cnt*NOTES_PER_OCTAVE; // BAD
sub_note_key_base = base_note_key + octave_cnt * NOTES_PER_OCTAVE; // GOOD

Ternary Operator

If long ternary expressions don't fit on one line, they MUST be formatted as below. If the expressions are very long or convoluted, you SHOULD use if/else blocks instead.

a == condition
	? value
	: otherValue;