Coding Guidelines
From KDevelop
KDevPlatform Policies
The following policies apply to the public API in the kdevplatform module, that is all the libraries in the top-level directory.
- kdelibs licensing policy, in short that means LGPL, BSD without advertisement clause, MIT or X11 more information in Licensing Policy
- complete documentation for all public API more information in Documentation Policy
- prepare for keeping BC even when extending the libraries, more information in Library Code Policy
- keep the formatting style of the library intact and port wrongly formatted functions if you touch large parts of them
- Always port both kdevelop and kdewebdev/quanta when doing API changes
- API design decisions should be discussed on the kdevelop-devel mailinglist, unless you're 100% sure you're doing the right thing.
Coding Guidelines
This document describes the ideal code formatting techniques for use in KDevelop. It is only meant to serve as a guide to help answer questions about how the majority of code in KDevelop is formatted.
- Coding style should be kept the same across the whole code of a KDevelop module. A KDevelop module can be:
- a plugin
- a utility library
- a set of interfaces
- The original author of the code has the right to define the coding style.
- Modelines for the various editors such as Kate, vim, or (x)emacs are greatly encouraged, although not required.
- Developers are expected to adhere to the coding style that is present within the module. This means
- stick to the original coding style when making modifications to existing code
- use the original coding style also when creating new files inside a module
- add same Kate/Vi modelines to the new files in the module.
- The original author can write a section in the module's Mainpage.dox file describing the coding style. A HACKING file can also be used. Possible contents include:
- the modeline that should be used in the files
- an example of the coding style
- Lines should be less than 80 characters wide if possible, maximum acceptable width is 100 characters. (Does not apply to generated files.)
If the author does not have strong personal preferences over the coding style (or wants to stick with the default KDevelop coding style), he/she is advised to pick following kate modeline:
// kate: space-indent on; indent-width 4; tab-width 4; replace-tabs on; auto-insert-doxygen on
An example of the default coding style is presented below:
namespace Foospace
{
class Bar: public Base
{
public:
Bar();
int foo();
private:
int m_foo;
};
Bar::Bar()
: Base()
{
}
int Bar::foo()
{
switch (x)
{
case 1:
break;
default:
break;
}
if (isBar)
{
bar();
return m_foo + 1;
}
else
return 0;
}
}
![[Main Page]](/graphics/theme3/KDevelopBigIcon.png)