1 Commit and coding guidelines for Veritas.
3 -- I. Coding Guidelines -------------------------------------------------------
5 KDELibs guidelines [1] apply with a couple of additions:
7 (1) methods should be short (max single screen) and focused on doing one
9 (2) limit nested control structures, ideally a method has less than two levels
11 (3) intent revealing names for classes and functions
12 (4) prefer composition over inheritance
13 (5) abbreviated variables are OK in functions
14 (6) all Veritas symbols live in the Veritas namespace
15 (7) single line 'if' statements are OK
17 In general, aim for readability.
19 Code checking with Krazy [2] is encouraged.
21 [1] http://techbase.kde.org/Policies/Kdelibs_Coding_Style
22 [2] http://www.englishbreakfastnetwork.org/krazy/
24 -- II. Commit Discipline ------------------------------------------------------
32 Both bug fixes and new features must be accompanied with unit tests to justify
33 the change and lock progress. In rare cases were unit tests require too
34 much effort manual tests are OK. If your change is absolutely positively
35 untestable it should go through the kdevelop-devel mailing list for approval.
36 Refactorings do not require extra tests.
38 No change will break any test. Commits that break previously running tests
39 are in for an instant revert. This may sound harsh but try to look at it
40 from the other side: much effort has gone into test writing, you don't want
41 to be the party pooper.
43 Tests that expose a bug or show a new feature that isn't fixed/implemented yet
44 can be committed. To make them stand out from the regression suite their names
45 shall be be prefixed with 'tdd', which stands for 'test driven development'.
47 -------------------------------------------------------------------------------