Policies/Frameworks Coding Style: Difference between revisions

From KDE TechBase
(Add section "Variable Declarations" with an updated example)
(Add section "Whitespace")
Line 3: Line 3:
== Indentation ==
== Indentation ==
* 4 spaces
* 4 spaces
* no tabs
* No tabs


== Variable Declarations ==
== Variable Declarations ==
Line 23: Line 23:
QString progressText;
QString progressText;
QString errorString;
QString errorString;
</syntaxhighlight>
== Whitespace ==
* Use blank lines to group statements
* Use only one empty line
* One space after each keyword
** Exception: No space between return and ';'
* For pointers or references, use a single space before '*' or '&', but not after
* No space after a cast
Example:
<syntaxhighlight lang="cpp-qt">
// wrong
QString* myString;
if(true){
}
// correct
QString *myString;
if (true) {
}
</syntaxhighlight>
</syntaxhighlight>



Revision as of 03:23, 29 November 2015

Note
This is a style guide for KDE Frameworks 5. If you write code that is not targeted at KF5, but only at KDE SC 4, refer to that style guide.


Indentation

  • 4 spaces
  • No tabs

Variable Declarations

  • Each variable declaration on a new line
  • Each new word in a variable name starts with a capital letter (so-called camelCase)
  • 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
KCategorizedView *catview;
QString prtxt, Errstr;

// correct
KCategorizedView *groupedDeviceList;
QString progressText;
QString errorString;

Whitespace

  • Use blank lines to group statements
  • Use only one empty line
  • One space after each keyword
    • Exception: No space between return and ';'
  • 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) {
}

Qt Includes

  • For Qt #includes omit the module name and only use the class name. That way chances are good that future migrations of Qt classes between different modules do not need any adjustments in the code.

Example:

// wrong
#include <QtCore/QString>

// correct
#include <QString>


Note
This policy applies to KF5 and is the exact opposite of the preferred style for kdelibs in KDE SC 4.