This repository was archived by the owner on Dec 17, 2017. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 78
Coding Style
SokoloffA edited this page Jul 4, 2011
·
11 revisions
This document describes the recommended coding style for Razor-qt project. Nobody is forced to use this style, but to have consistent formatting of the source code files it is recommended to make use of it.
- No tabs
- 4 Spaces instead of one tab
- Each variable declaration on a new line
- Each new word in a variable name starts with a capital letter (so-called camelCase)
- Underlining is used only for special cases
- All class members must be prefixed with 'm'
- Avoid abbreviations
- Take 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
Example:
// wrong
KProgressBar *prbar;
QString prtxt, errstr, file_Name;
class A
{
private:
int count;
}
// correct
KProgressBar *downloadProgressBar;
QString progressText;
QString errorString;
DbusMounter busMounter_hal;
DbusMounter busMounter_udisk;
class A
{
private:
int mCount;
}
- Use blank lines to group statements
- 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)
{
}
???
Case labels are on the same column as the switch
Example:
// correct
switch (myEnum)
{
case Value1:
doSomething();
break;
case Value2:
doSomethingElse();
// fall through
default:
defaultHandling();
break;
}
Try to keep lines shorter than 100 characters, inserting line breaks as necessary.
If you add #includes for Qt classes, use both the module and class name. This allows library code to be used by applications without excessive compiler include paths. Example:
// wrong
#include <QString>
// correct
#include <QtCore/QString>