• Skip to content
  • Skip to link menu
KDE PIM
  • KDE PIM / General
 
 

KOrganizer Coding Style

This document describes the basic guidelines for hacking on KOrganizer, libkcal and libkabc.

Formatting

  • No Tabs
  • Indent with 2 spaces
  • A line must not have more than 80 chars
  • If the arguments of a function don't fit into the 80 chars, start a new line and align the additional arguments with the first one.
  • Put spaces between operators and arguments
  • Put spaces between brackets and arguments of functions
  • For pointer and reference variable declarations put a space between the type and the * or & and no space before the variable name.
  • For if, else, while and similar statements put the brackets on the same line as the statement
  • Function and class definitions have their brackets on separate lines

void MyClass::myFunction( MyPointer *pointer, MyReference &ref,
                          Argl *oerx )
{
  if ( blah == false ) {
    blubbVariable = arglValue;
  } else {
    blubbVariable = oerxValue;
  }
}

Header Formatting

  • General formatting rules apply
  • Access modifiers are indented
  • Put curly brackets of class definitions on its own line
  • Double inclusion protection defines are all upper case letters and are composed of the namespace (if available), the classname and a H suffix separated by underscores
  • Inside a namespace there is no indentation
#ifndef XKJ_MYCLASS_H
#define XKJ_MYCLASS_H

namespace XKJ {

class MyClass
{
  public:
    MyClass();

  private:
    int mMyInt;
};

}

#endif

API docs

  • Each public function must have a Doxygen compatible comment in the header
  • Use C-style comments without additional asterisks
  • Comments should be grammatically correct, e.g. sentences start with uppercase letters and end with a full stop
  • Be concise
  /**
    This function makes tea.

    @param cups number of cups.
    @result tea
  */
  Tea *makeTea( int cups );

Class and File Names

  • Put classes in files, which have the same name as the class, but only lower-case letters
  • Designer-generated files should have a name classname_base.ui and should contain a class called ClassnameBase
  • Classes inheriting from designer-generated classes have the same name as the generated class, but without the Base suffix

Class and Variable Names

  • For class, variable, function names separate multiple words by upper-casing the words preceded by other words
  • Class names start with an upper-case letter
  • Function names start with a lower-case letter
  • Variable names start with a lower-case letter
  • Member variables of a class start with "m" followed by an upper-case letter

Misc

  • Use true and false instead of TRUE and FALSE. These are the C++ keywords after all.
  • A null pointer is 0, not 0l, 0L or NULL. Once again, this is C++, not C.

[ Edit ]

Information

Skip menu "Information"
  • Home
  • Mission
  • News
  • Contact

Community

Skip menu "Community"
  • Meetings
  • History
  • People
  • Team

Development

Skip menu "Development"
  • General
  • Coding Style
  • Bug Reports
  • Architecture
  • Akonadi
  • Tutorials
  • Applications
  • Glossary

Website

Skip menu "Website"
  • Contribute

Global navigation links

  • KDE Home
  • KDE Accessibility Home
  • Description of Access Keys
  • Back to content
  • Back to menu

Search:


Maintained by pim.kde.org Webmaster
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V. | Legal