2.5. Programming Conventions

KDE developers follow certain conventions when they write KDE source code. The conventions dictate naming and documentation styles. Following them will help other developers to work with your code more easily. It will even help you. For example, you won't have to look up names of methods as often because the conventions make the names easier to remember.

2.5.1. Naming Conventions

KDE class names begin with a capital K. The first letter of each word making up the class name is also capitalized. For example, you used KSimpleApp as your class name in the code in Listings 2.3–2.5. Note that Qt class names follow a similar convention, but they all start with a capital Q.

The names of methods begin with a lowercase letter, but the first letter of each successive word is capitalized. For example, the method setBackgroundColor(), used in the constructor for KSimpleApp, is named with this convention. It is a Qt method (a member of QWidget) and follows the convention, as do all Qt methods.

Class and method names usually consist of one or more whole words or common abbreviations (such as "App" for application in the name KSimpleApp). Whole word names are easier to remember and make for more readable code.

Conventions are also used for filenames. Header files containing class definitions are given the name of the class, except that all letters are kept lowercase. The extension .h is used. Source files containing class definitions also use an all-lowercase version of the class name and carry the extension .cpp.

Prototypical examples of the naming conventions are collected in Table 2.2.

Table 2.2. KDE Naming Conventions

Type	Prototype
Class	KMyGreatClass
Method	myUsefulMethod
Class declaration file	kmygreatclass.h
Class description file	kmygreatclass.cpp

2.5.2. Class Documentation

It is important to document the public interfaces to your classes so that others may make use of them in their programs when hacking at your code. You should also document the protected interface so that derivation is easier. Listing 2.3 gives examples of the class documentation style. If the documentation is given in the comments in this form, it can be interpreted by a script called kdoc, which can create attractive, standalone documentation. kdoc-style documentation is covered in depth in Chapter 15, "Creating Documentation."