Official:Code guidelines and formatting conventions: Difference between revisions
m (Protected "Official:Code guidelines and formatting conventions" ([edit=sysop] (indefinite) [move=sysop] (indefinite))) |
(Add guideline for included source code headers) |
||
Line 19: | Line 19: | ||
} | } | ||
} | } | ||
</pre> | |||
=== Headers === | |||
Included source files *.cpp and *.h, are to sort alphabetical to prevent double used file definition and allow better overview | |||
* On cpp define used header first to confirm needed headers are present on them itself | |||
* As next use the global system headers e.g. <cassert> or "system.h" | |||
* Then insert all the headers needed for the file itself | |||
<pre> | |||
#include "PVRManager.h" | |||
#include <cassert> | |||
#include <utility> | |||
#include "Application.h" | |||
#include "Util.h" | |||
#include "addons/AddonInstaller.h" | |||
#include "dialogs/GUIDialogExtendedProgressBar.h" | |||
... | |||
#include "messaging/helpers/DialogHelper.h" | |||
#include "music/tags/MusicInfoTag.h" | |||
#include "network/Network.h" | |||
#include "pvr/addons/PVRClients.h" | |||
#include "pvr/channels/PVRChannel.h" | |||
... | |||
#include "settings/Settings.h" | |||
#include "threads/SingleLock.h" | |||
#include "utils/JobManager.h" | |||
#include "utils/log.h" | |||
... | |||
#include "utils/Variant.h" | |||
#include "video/VideoDatabase.h" | |||
</pre> | </pre> | ||
Revision as of 23:49, 9 November 2015
Development | Code guidelines and formatting conventions |
These are conventions which we try to follow when writing code for Kodi. They are this way mainly for reasons of taste, however, sticking to a common set of formatting rules also makes it slightly easier to read through our sources. If you want to submit patches, please try to follow these rules.
As such we don't follow these rules slavishly, in certain cases it is ok (and in fact favorable) to stray from them.
Indentation
Use spaces as tab policy with an indentation size of 2
Namespaces
Namespaces are not required to use any indentation to simplify nested namespaces and wrapping .cpp files in a namespace
namespace KODI { namespace UTILS { class ILogger { void Log(...) = 0; } } }
Headers
Included source files *.cpp and *.h, are to sort alphabetical to prevent double used file definition and allow better overview
- On cpp define used header first to confirm needed headers are present on them itself
- As next use the global system headers e.g. <cassert> or "system.h"
- Then insert all the headers needed for the file itself
#include "PVRManager.h" #include <cassert> #include <utility> #include "Application.h" #include "Util.h" #include "addons/AddonInstaller.h" #include "dialogs/GUIDialogExtendedProgressBar.h" ... #include "messaging/helpers/DialogHelper.h" #include "music/tags/MusicInfoTag.h" #include "network/Network.h" #include "pvr/addons/PVRClients.h" #include "pvr/channels/PVRChannel.h" ... #include "settings/Settings.h" #include "threads/SingleLock.h" #include "utils/JobManager.h" #include "utils/log.h" ... #include "utils/Variant.h" #include "video/VideoDatabase.h"
Braces
Braces should go to newline and your code should look like the following example:
if (int i = 0; i < t; i++) { [...] } else { [...] } class Dummy() { [...] }
Whitespaces
Conventional operators should be surrounded by a whitespace.
a = (b + c) * d;
Reserved words should be separated from opening parentheses by a whitespace.
while (true) for (int i = 0; i < x; ++i)
Commas should be followed by a whitespace.
void Dummy::Method(int a, int b, int c); int d, e;
Semicolons should be followed by a whitespace if there is more than one expression per line.
for (int i = 0; i < x; ++i) doSomething(e); doSomething(f); // this is probably bad style anyway
Control statements
Insert new line before
- else in an if statement
- catch in a try statement
- while in a do statement
if else
- put then statement, return or throw to new line
- keep else if on one line
if (true) return; if (true) { [...] } else if (false) { return; } else return;
switch / case
switch (cmd) { case x: { doSomething(); break; } case x: case z: return true; default: doSomething(); }
Naming
Namespaces
Namespaces should be in uppercase letters
namespace KODI { ... }
Constants
Use upper case with underscore spacing where necessary.
const int MY_CONSTANT = 1;
Enums
Use CamelCase for the enum name and upper case for the values.
enum Dummy { VALUE_X, VALUE_Y };
Interfaces
We use CamelCase for interface names and they should be prefixed with an uppercase I. Filename should match the interface name, e.g. ILogger.h
class ILogger { void Log(...) = 0; }
Classes
We use CamelCase for class names and they should be prefixed with an uppercase C. Filename should match the class name without the prefixed C, e.g. Logger.cpp
class CLogger : public ILogger { void Log(...) }
Methods
We use CamelCase for method names and first letter should be upper case.
void MyDummyClass::DoSomething();
Variables
We use CamelCase for variables. Type prefixing is optional.
Global Variables
Prefix global variables with g_
int g_globalVariableA;
Member Variables
Prefix member variables with m_
int m_variableA;
Conventions
Casts
New code should use C++ style casts and not older C style casts. When modifying existing code the developer can choose to update it to C++ style casts or leave as is. Remember that whenever a dynamic_cast is used the result can be a nullptr and needs to be checked accordingly.
NULL vs nullptr
Prefer the use of nullptr instead of NULL. nullptr is a typesafe version and as such can't be implicitly converted to int or anything else.
auto
Feel free to use auto wherever it improves readability. Good places are iterators or when dealing with containers.
std::map<std::string, std::vector<int>>::iterator i = var.begin(); vs auto i = var.being();
for loops
Use newer style foreach loops whenever it makes sense. If iterators are used see above about using auto.
for (auto& : var) { ... }
Use const auto& if there's no reason to modify the value.