1Since 1999, people have been hacking on Krita. Everyone brought their
2own coding style, their own code conventions, their own likes and
3dislikes. Me, (Boudewijn that is), I like indents of four spaces, and
4no scope prefixes for variables. However, in the interests of
5consistency, these are the rules new code should adhere to:
6
7See also https://community.kde.org/Policies/Frameworks_Coding_Style --
8that document is leading.
9
10Qt vs STD vs Boost:
11
12    In general, use the Qt classes wherever possible, even if someone tells you
13    that the STD class is better or whatever. We're dealing with a big project
14    with lots of developers here and we should keep the code as consistent and
15    easy to grasp as possible. Since people need to know Qt in the first place,
16    keep to Qt. Discuss deviations on #krita
17
18C++11 and C++14
19
20    Yes, but. Avoid lambdas (except when replacing the use of
21    QSignalMapper. Sigh.).  Avoid the new sig/slot connection syntax
22    _unless_ you are porting all of Krita to the new syntax. Sure, it
23    has some advantages, but having two different ways of doing the same
24    thing is begging for trouble and comprehension problems. For now,
25    keep using Q_FOREACH, we're using it all over the place. auto is fine,
26    when using in for loops. Don't go use it in other places.
27
28    Before using other new features, discuss on #krita so we can expand this list.
29
30    Our minimum gcc version is 4.5, shipped with Ubuntu 12.04
31
32
33Indentation
34
35	With four spaces. Use the default kdelibs indentation
36    (http://techbase.kde.org/Policies/Kdelibs_Coding_Style)
37
38Includes
39
40	Avoid as much as possible #includes in header files; use forward declarations
41	of classes.
42
43Initializers
44
45	Avoid as much as possible initializers in the body of the constructor. Use
46	initializer lists instead. Write the initializers as follows
47
48    Class(A a, B b)
49        : Subclass(a)
50        , m_b(b)
51    {
52    }
53
54    Note the location of the colon and comma.
55
56    It is also okay to use initializers like, and maybe even preferred where it works.
57
58    int m_something {0};
59
60Scope prefixes
61
62	Use only m_ for class-level variables. No other scope prefixes; no g_, l_,
63	no 'p' for pointer variables.
64
65Shared pointers
66
67	Use shared pointers wherever possible. Prefer Qt's shared pointer classes
68    to our home-grown shared ppointer classes.
69
70Getter/setter
71
72	Krita doesn't use Qt's properties -- yet. If you want to introduce use of
73	properties, convert any and all classes in Krita before committing.
74
75	Getter/setters are named 'x() for getters and setX(int x) for setters. If you
76	come across violations of this rule, change the code.
77
78Class naming
79
80	If you use a well-known design pattern, name the class according to the design
81	pattern. All files should start with 'Kis', all classes with the 'Kis' prefix.
82    This filename should be the same as the classname: KisNewClass.h, KisNewClass.
83
84Function naming
85
86	Functions should be named in camelBackedFashion, to conform to Qt's standards.
87	If you encounter functions in c_style_like_this, feel free to rename. Also:
88	verbNoun -- i.e., rotateLayer, not layer_rotate. The latter is a true c-ism,
89	introduced by a language that needs to prefix the 'class' name to every function
90	in order to have something that's not quite OO.
91
92Variable/Parameter names
93
94	Variable/parameter names start with a lower case letter. A name composed of different
95	words is done in camelBackedStyle.
96
97Designer
98
99	Krita has started to use designer. All dialogs and all widgets that have a layout
100	manager must be done in designer. Do not add code or signal/slot connections
101	in designer.
102
103Enums
104
105	All enums should be prefixed with 'enum'.
106
107Namespaces
108
109	Currently, we only use anonymous namespaces for things like undo
110	commands. For the rest, some classes have a 'Kis' prefix, others don't. This should
111	be made consistent, and we might want to use namespaces to keep all of Krita
112	inside.
113
114Files and classes
115
116	It's preferred (and strongly preferred) to have only one class per .h/.cpp file.
117	(Which is logical, because otherwise you won't be able to keep to the naming scheme.)
118
119Spaces
120
121	Keep the source airy and open. In particular, there should be empty lines between function
122    declarations and definitions.
123
124Slots and signals
125
126	Prefix slots with slot and signals with sig: slotUpdateSelection, sigSelectionUpdated.
127
128Boolean operators
129
130    Use the standard !, !=, ==, && etc style, not the "not", "and" etc. style. Keep krita code
131    using one, easily recognizable, C++ style.
132
133
134Boudewijn Rempt
135
136
137With Krita now supporting Python scripting, we need guidelines for these as well.
138These guidelines are preliminary and may be further refined in the future.
139
140To keep it simple, we have chosen to follow the style guide suggested by Python: PEP8.
141
142All rules should be followed, except the max limit of 79 characters per line. As this
143can reduce readability in some cases, this rule is optional.
144
145The full PEP8 specification is available here: https://www.python.org/dev/peps/pep-0008/
146
147To check compliance you can run pep8.py against the code.
148You can also use autopep8.py to automatically fix detected compliance issues.
149
150pep8.py can be downloaded via Python's package manager (pip) [https://pypi.python.org/pypi/pep8],
151or your distribution's package manager.
152autopep8.py can also be downloaded via Python's package manager [https://pypi.python.org/pypi/autopep8],
153or your distribution's package manager.
154
155Both of these scripts come bundled with the PyDev plugin, which is available for Eclipse and other IDEs.
156The PyDev integration can be configured to visually highlight portions of the code which is not in compliance,
157as well as run autopep8 via shortcuts.
158
159pep8.py and autopep8.py can suppress select rules via the "--ignore" command line argument.
160To ignore the 79 characters per line rule, pep8.py can be called like this:
161
162pep8.py --ignore=E501
163
164You can read more about the error codes and what they mean here:
165http://pep8.readthedocs.io/en/release-1.7.x/intro.html#error-codes
166