-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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 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.
The first #include
in a cpp
file MUST be its own related header file. Afterwards group #include
s 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"
Types MUST begin with an uppercase letter.
class ResourcesDB;
enum MyEnum
{
...
};
typedef QList<AutomatableModel *> AutoModelList;
Variables MUST use camel case format, for example: nextValue
.
- Non-static member variables MUST be prefixed with
m_
- Static variables MUST be prefixed with
s_
The remaining variable name MUST follow the Variable Names rule.
float m_currentValue;
static int s_quantization;
Some older code prefixed function parameters with an underscore _
. Function parameters SHOULD NEVER be prefixed with an underscore.
Every line of text SHOULD be at most 120 characters long.
Tabs MUST be used for indentation. Instructions for configuring QtCreator can be found here.
Flow control statements (if
, else if
, else
, for
, do
, while
, and switch
) MUST have a space between the keyword and the opening parenthesis.
You MUST use the true
/false
keywords instead of non-standard macros.
b = TRUE; // BAD
b = true; // GOOD
b = 1; // BAD
The ternary operator ? :
SHOULD ONLY be used when it makes the code more readable or streamlined.
- Spaces CANT be added after an opening brace
- Spaces CANT be added before a closing brace
- Flow control statements (
if
,else if
,else
,for
,do
,while
, andswitch
) MUST use explicit blocking - 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 CANT have parenthesis around the returned value.
return (bar); // BAD
return bar; // GOOD
Spaces CANT be added before semicolons.
return this ; // BAD
return this; // GOOD
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
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;