Newer Older
1 2 3 4 5 6
Since 1999, people have been hacking on Krita. Everyone brought their
own coding style, their own code conventions, their own likes and
dislikes. Me, (Boudewijn that is), I like indents of four spaces, and
no scope prefixes for variables. However, in the interests of
consistency, these are the rules new code should adhere to:

7 8
See also http://techbase.kde.org/Policies/Kdelibs_Coding_Style -- that document
is leading.

10 11 12 13 14 15 16 17 18 19
Qt vs STD vs Boost:

    In general, use the Qt classes wherever possible, even if someone tells you
    that the STD class is better or whatever. We're dealing with a big project
    with lots of developers here and we should keep the code as consistent and
    easy to grasp as possible. Since people need to know Qt in the first place,
    keep to Qt. Discuss deviations on #krita

C++11 and C++14

20 21 22 23 24 25 26
    Yes, but. Avoid lambdas (except when replacing the use of
    QSignalMapper. Sigh.).  Avoid the new sig/slot connection syntax
    _unless_ you are porting all of Krita to the new syntax. Sure, it
    has some advantages, but having two different ways of doing the same
    thing is begging for trouble and comprehension problems. For now,
    keep using Q_FOREACH, we're using it all over the place. auto is fine,
    when using in for loops. Don't go use it in other places.
27 28 29

    Before using other new features, discuss on #krita so we can expand this list.

30 31
    Our minimum gcc version is 4.5, shipped with Ubuntu 12.04


33 34

35 36
	With four spaces. Use the default kdelibs indentation 
37 38 39 40 41 42 43 44 45


	Avoid as much as possible #includes in header files; use forward declarations
	of classes.


	Avoid as much as possible initializers in the body of the constructor. Use
Boudewijn Rempt's avatar
Boudewijn Rempt committed
	initializer lists instead. Write the initializers as follows
Boudewijn Rempt's avatar
Boudewijn Rempt committed
47 48 49 50 51 52

    Class(A a, B b)
        : Subclass(a)
        , m_b(b)

Boudewijn Rempt's avatar
Boudewijn Rempt committed
54 55 56 57 58 59
    Note the location of the colon and comma.

    It is also okay to use initializers like, and maybe even preferred where it works.

    int m_something {0};

60 61 62 63 64 65 66
Scope prefixes

	Use only m_ for class-level variables. No other scope prefixes; no g_, l_,
	no 'p' for pointer variables.

Shared pointers

Boudewijn Rempt's avatar
Boudewijn Rempt committed
67 68
	Use shared pointers wherever possible. Prefer Qt's shared pointer classes
    to our home-grown shared ppointer classes.
69 70 71 72 73 74


	Krita doesn't use Qt's properties -- yet. If you want to introduce use of
	properties, convert any and all classes in Krita before committing.

	Getter/setters are named 'x() for getters and setX(int x) for setters. If you
76 77 78 79 80
	come across violations of this rule, change the code.	

Class naming

	If you use a well-known design pattern, name the class according to the design
Boudewijn Rempt's avatar
Boudewijn Rempt committed
81 82
	pattern. All files should start with 'Kis', all classes with the 'Kis' prefix.
    This filename should be the same as the classname: KisNewClass.h, KisNewClass.

84 85 86 87 88 89
Function naming

	Functions should be named in camelBackedFashion, to conform to Qt's standards.
	If you encounter functions in c_style_like_this, feel free to rename. Also:
	verbNoun -- i.e., rotateLayer, not layer_rotate. The latter is a true c-ism,
	introduced by a language that needs to prefix the 'class' name to every function
Boudewijn Rempt's avatar
Boudewijn Rempt committed
	in order to have something that's not quite OO.

92 93
Variable/Parameter names

Frederik Gladhorn's avatar
Frederik Gladhorn committed
	Variable/parameter names start with a lower case letter. A name composed of different
95 96
	words is done in camelBackedStyle.

97 98

	Krita has started to use designer. All dialogs and all widgets that have a layout
Frederik Gladhorn's avatar
Frederik Gladhorn committed
100 101
	manager must be done in designer. Do not add code or signal/slot connections
	in designer.
102 103 104 105 106 107 108


	All enums should be prefixed with 'enum'.


Boudewijn Rempt's avatar
Boudewijn Rempt committed
	Currently, we only use anonymous namespaces for things like undo
110 111
	commands. For the rest, some classes have a 'Kis' prefix, others don't. This should
	be made consistent, and we might want to use namespaces to keep all of Krita
Patrick Julien's avatar
Patrick Julien committed
112 113

114 115 116 117 118
Files and classes

	It's preferred (and strongly preferred) to have only one class per .h/.cpp file.
	(Which is logical, because otherwise you won't be able to keep to the naming scheme.)

119 120

Boudewijn Rempt's avatar
Boudewijn Rempt committed
121 122
	Keep the source airy and open. In particular, there should be empty lines between function
    declarations and definitions.
123 124 125

Slots and signals

	Prefix slots with slot and signals with sig: slotUpdateSelection, sigSelectionUpdated.

Boudewijn Rempt's avatar
Boudewijn Rempt committed
128 129 130 131 132 133 134
Boolean operators

    Use the standard !, !=, ==, && etc style, not the "not", "and" etc. style. Keep krita code
    using one, easily recognizable, C++ style.

Boudewijn Rempt