Policies/Frameworks Coding Style
Note
Indentation
- No tabs
- 4 Spaces instead of one tab
Variable declaration
- Each variable should be declared on a new line
- Each new word in a variable name starts with a capital letter (so-called camelCase)
- Avoid abbreviations
- Use indicative/useful names. No short names, except:
- Single character variable names can denote counters and temporary variables whose purpose is obvious
- Variables and functions start with a lowercase letter
- Member variable names should be prefixed with m_ to make it easier to distinguish them from function parameters and local variable names
- The same applies to Private (d-pointer) class member variable names, (it may be a bit overkill when the Private class is merely used as a struct and all the code is in the public class, so you can use the m_ prefix everywhere to keep it consistent, or switch to prefixing m_ when adding the first method to a Private class)
- Static (global) variable names should be prefixed with s_
Example:
// wrong
KProgressBar *prbar;
QString prtxt, errstr;
// correct
KProgressBar *downloadProgressBar;
QString progressText;
QString errorString;
Whitespace
- Use blank lines to group statements
- Use only one empty line
- Use one space after each keyword
- For pointers or references, use a single space before '*' or '&', but not after
- No space after a cast
Example:
// wrong
QString* myString;
if(true){
}
// correct
QString *myString;
if (true) {
}
Enumerations
Ideally it should be one member per line.
Always add a trailing comma to the last member in an Enumeration. This helps produce better diffs (and has the good side-effect that code formatting tools, e.g. clang-format, will not put the whole enum on one line).
The same rule in the Braces section below applies, i.e. the left curly brace goes on the same line as the start of the statement.
Example:
// Wrong
enum ViewType
{
FullView,
CompactView
};
// Correct
enum ViewType {
FullView,
CompactView, // The last enum member should have a trailing comma
};
Braces
As a base rule, the left curly brace goes on the same line as the start of the statement.
Example:
// wrong
if (true)
{
}
enum ViewType
{
FullView,
CompactView
};
// correct
if (true) {
}
enum ViewType {
FullView,
CompactView,
};
Exception: Function implementations, class, struct and namespace declarations always have the opening brace on the start of a line.
Example:
void debug(int i)
{
qDebug("foo: %i", i);
}
class Debug
{
};
Use curly braces even when the body of a conditional statement contains only one line.
Example:
// wrong
if (true)
return true;
for (int i = 0; i < 10; ++i)
qDebug("%i", i);
// correct
if (true) {
return true;
}
for (int i = 0; i < 10; ++i) {
qDebug("%i", i);
}
Switch statements
Case labels are on the same column as the switch
Example:
switch (myEnum) {
case Value1:
doSomething();
break;
case Value2:
doSomethingElse();
// fall through
default:
defaultHandling();
break;
}
Line breaks
Try to keep lines shorter than 100 characters, inserting line breaks as necessary.
Qt Includes
- If you add #includes for Qt classes, use only the class name.
Example:
// wrong
#include <QtCore/QString>
// correct
#include <QString>
Clang-format automatic code formatting
By including the KDEClangFormat CMake module the .clang-format file is copied into the source folder. Using the provided `kde_clang_format` function one can create a target which formats all given files. Projects can enforce the formatting using a pre-commit hook which uses the "git clang-format" tool to ensure the changes are properly formatted.
Tips and tricks:
// without trailing comma to enums and initializer lists
enum ViewType { FullView, CompactView };
const QStringList values = {QStringLiteral("value1"), QStringLiteral("value2")};
// with trailing comma to enums and initializer lists
enum ViewType {
FullView,
CompactView,
};
const QStringList values = {
QStringLiteral("value1"),
QStringLiteral("value2"),
};
// the statement is longer than 160 characters, clang-format will break it into two lines
const QStringList result =
MyVeryVeryLongFunction(QStringLiteral("averyverylongparameterforthisfunction"), QStringLiteral("averyverylongparameterforthisfunction"));
// using a comment at the end to preserve the a manual linebreak
const QStringList result = MyVeryVeryLongFunction(QStringLiteral("averyverylongparameterforthisfunction"), //
QStringLiteral("averyverylongparameterforthisfunction"));
// here the indentation feels a bit off because it is only indented one tab and not relatively to the variable declaration
int resultFromComplexCalculation = someveryveryveryveryveryveryveryveryveryveryveryveryverylongvariablename1
+ someveryveryveryveryveryveryveryveryveryveryveryveryverylongvariablename2
+ someveryveryveryveryveryveryveryveryveryveryveryveryverylongvariablename3;
// adding parentheses around the entire statement will ensure sure it is indented relatively to the variable declaration
int resultFromComplexCalculation = (someveryveryveryveryveryveryveryveryveryveryveryveryverylongvariablename1
+ someveryveryveryveryveryveryveryveryveryveryveryveryverylongvariablename2
+ someveryveryveryveryveryveryveryveryveryveryveryveryverylongvariablename3);
Also the formatting can be turned off for specific parts.
// clang-format off
Some fragile or from third parties imported code...
// clang-format on
But you should be careful with excluding parts from the formatting and only do this when it would break code or it would require too many manual interventions as suggested above
Document started by Urs Wolfer. Some parts of this document have been adopted from the Qt Coding Style document posted by Zack Rusin on kde-core-devel.