m (style++) |
(list 'kdelibs coding style' + linkify api dox howto) |
||
| Line 12: | Line 12: | ||
;[[/Library Documentation Policy|Library Documentation Policy]] | ;[[/Library Documentation Policy|Library Documentation Policy]] | ||
| − | :Libraries for (re)use should be completely documented. This policy explains why | + | :Libraries for (re)use should be completely documented. This policy explains why as well as how to document things, and what style to follow. The [[Development/Tutorials/API Documentation|apidox howto]] contains more technical information on writing documentation for libraries. |
;[[/Library Code Policy|Library Code Policy]] | ;[[/Library Code Policy|Library Code Policy]] | ||
| − | :KDE Library API and Code should follow some conventions that are explained in this policy | + | :KDE Library API and Code should follow some conventions that are explained in this policy. |
| + | |||
| + | ;[[/Kdelibs Coding Style|Kdelibs Coding Style]] | ||
| + | :This document describes the recommended coding style for kdelibs. Nobody is forced to use this style, but to have consistent formating of the source code files it is recommended to take use of it. | ||
;[[/Binary Compatibility Issues With C++|Binary Compatibility Issues With C++]] ([http://developer.kde.org/documentation/other/binarycompatibility.html Original]) | ;[[/Binary Compatibility Issues With C++|Binary Compatibility Issues With C++]] ([http://developer.kde.org/documentation/other/binarycompatibility.html Original]) | ||
There are a couple of written and unwritten rules KDE developers usually adhere to. The following documents summarize some of these policies. The list is still incomplete. If you are interested in helping out with formulating the KDE policies or would like to discuss them please use the kde-policies mailing list which was created for this purpose.
These policies apply to KDE developers and it is expected that all persons with a KDE SVN account follow these policies. The SVN commit policy is the most important one. Persons working on libraries (kdelibs mostly, but central libraries in other SVN modules fall under this as well) should read the library documentation policy (and the apidox howto as well).
Whereas policies are normative for individual developers -- that is, they describe how developers must behave -- procedures describe how 'the KDE project' as a whole has chosen to behave. We describe what we will do under certain circumstances and why.