Перевод "KDE Policies/Library Code Policy"

Olivier Goffart, “KDE Policies/Library Code Policy”, public translation into Russian from English More about this translation.

See also 6 similar translations

Translate into another language.

Participants

Join Translated.by to translate! If you already have a Translated.by account, please sign in.
If you do not want to register an account, you can sign in with OpenID.
Pages: ← previous Ctrl next next untranslated
1 2 3 4 5 6 7 8 9

KDE Policies/Library Code Policy

This document describes some of the recommended conventions that should be applied in the KDE libraries (not applications). Respecting these guidelines helps create a consistant API and also may help ease maintainence of the libraries later. While these conventions are not mandatory, they are important guidelines, and should be respected unless you have a good reason to disregard them.

As an introduction, you should read the document Designing Qt-Style C++ APIs.

For kdelibs, it is recommended to follow the Kdelibs Coding Style. Contents

[hide]

1 Naming Conventions

2 D-Pointers

2.1 Shared D-Pointers

2.2 Q_DECLARE_PRIVATE

2.3 Q-Pointers

3 Inline Code

4 Flags

5 Const References

6 Signals and Slots

7 Properties

8 Explicit Constructors

9 Avoid including other headers in headers

10 Getting #includes right

10.1 As application developer

10.2 As library developer

10.3 Include order

10.4 Include guards

11 Static Objects

12 Signal and Slot Normalization

13 Documentation

Naming Conventions

In KDE, we basically follow the same naming conventions as Qt.

Class names starts with a capital K. The rest is in camel case. Function names starts with a lower case, but the first letter of each successive word is capitalized.

Unless dealing with central libraries (kdecore, kdeui), classes should be in the library namespace. In that case, it is the namespace which starts with K and the classes inside may not start with it. New libraries should choose their namespace.

The prefix 'set' is used for setters, but the prefix 'get' is not used for accessors. Accessors are simply named with the name of the property they access. The exception is for accessors of a boolean which may start with the prefix 'is'.

Acronyms are lowercased too. Example: KUrl instead of KURL and isNssEnabled() instead of isNSSEnabled()

Accessors should usually be const.

This example shows some possible functions names

public:

void setColor(const QColor& c);

QColor color() const;

void setDirty(bool b);

bool isDirty() const;

Pages: ← previous Ctrl next next untranslated
1 2 3 4 5 6 7 8 9