summaryrefslogtreecommitdiff
path: root/HACKING
blob: a2c4d1f2f051e79e82fc8c3cbdb62c92b162ae73 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
Contents:

• Version control
• Coding style...
  › ...for C++ code
  › ...for C and Python code
• Submitting patches


===============================================================================
Version control
===============================================================================

The current development version of telepathy-qt is available from the
'master' branch in the git repository:

  <git://anongit.freedesktop.org/telepathy/telepathy-qt>
  <ssh://git.freedesktop.org/git/telepathy/telepathy-qt> (for committers)
  <http://cgit.freedesktop.org/telepathy/telepathy-qt/> (cgit)

Stable branches are available from branches with names like
'telepathy-qt-0.2' in the same repository.


===============================================================================
Coding style
===============================================================================

For C++ code:
-------------

TelepathyQt uses the standard Qt coding style for the Qt/C++ code, as also
followed by eg. KDELibs.  The coding style is described in more detail in the
KDE TechBase at <http://techbase.kde.org/Policies/Kdelibs_Coding_Style>; in
short, it amounts to:

 * 4 spaces for indentation (no tabs, anywhere)
 * javaCase for variables and functions (incl. members), FullCamelCase for types
 * No abbreviations, except for 100% standard ones like regex, refcount, etc.
 * Type &var and Type *var, not Type& var and Type* var for pointers and refs
 * Use only one empty line to separate both groups of related statements AND
   function & class bodies
 * Use a space after each keyword but none after opening parens (if (true))
 * No spaces between the function name and the parens for the parameter list
 * Surround binary operators with spaces, but don't put spaces between a unary
   operator and their operand
 * For function bodies, put the opening curly brace on its own line. For
   everything else, put the opening curly brace in the same line as the
   statement (if, for, etc.) associated with it.
 * Use curly braces even for single-line bodies of conditional statements and
   loops
 * Prefer static_cast, const_cast etc over C-style casts
 * Wrap long lines to 100 characters at most
 * Use foreach, emit instead of Q_FOREACH/Q_EMIT
 * Don't write long (> ~5 lines) inline methods unless they are needed because of
   eg. template
 * Don't use references to QObjects
 * Destroy transient objects such as method call watchers as soon as possible
   rather than accumulating them to long-lived parent objects
 * Documentation should be in the source file instead of the header file
 * Public xxxInterface methods' definitions should be added to the end of the
   public methods declaration.
 * Always add friend struct Private declaration on classes that have Private
   structure.
 * Always add Q_DISABLE_COPY(xxx) to classes that cannot be copied.
 * Q_DISABLE_COPY(xxx) declaration must be placed on the top of the class
   definition, before the public keyword.
 * Methods should be ordered as follows:
    public
    public Q_SLOTS
    Q_SIGNALS
    protected
    protected Q_SLOTS
    private Q_SLOTS
    private
 * friend class xxx definitions must be placed right below the private keyword.
 * All exported classes should use TP_QT_EXPORT macro as following:
    class TP_QT_EXPORT xxx { ... };
 * Every issue in APIs which can (or will) only be fixed later should be marked
   with a doxygen \todo and have a corresponding fd.o bug filed and mentioned in
   the \todo annotation


For C and Python code:
----------------------

Parts of the regression tests — namely, those parts in tests/lib/glib/ — are
taken from telepathy-glib, and are written in C; the majority of the code
generation tools — in tools/ — are written in Python. Please follow
<http://telepathy.freedesktop.org/wiki/Style> for these.


===============================================================================
Submitting patches
===============================================================================

Patches should be made as (preferably) git branches or (last resort) -uNr diffs
against upstream git master, as found at:

  git://anongit.freedesktop.org/telepathy/telepathy-qt
  ssh://git.freedesktop.org/git/telepathy/telepathy-qt (for committers)
  http://cgit.freedesktop.org/telepathy/telepathy-qt/ (cgit)

Patches can be announced at the freedesktop.org bugzilla, using the product
"Telepathy" and component "tp-qt":

  https://bugs.freedesktop.org/enter_bug.cgi?product=Telepathy&component=tp-qt

If submitting a Git branch, please set the URL field of the bug to point to
your Git branch. Regardless of whether you are referring to a Git branch or
attaching patches, please specify the "patch" keyword on the bug.

For details on the code review procedure, see:

  http://telepathy.freedesktop.org/wiki/Review%20Procedure