File: HACKING

package info (click to toggle)
telepathy-logger-qt 17.09.0-1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm, bullseye
  • size: 856 kB
  • sloc: python: 3,801; cpp: 2,212; xml: 1,001; sh: 126; makefile: 7
file content (93 lines) | stat: -rw-r--r-- 4,002 bytes parent folder | download | duplicates (5)
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
Contents:

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

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

The current development version of QTpLogger is available from a scratch repo:

    <http://quickgit.kde.org/?p=scratch%2Fsanfilippo%2Ftelepathy-logger-query.git&a=summary>

===============================================================================
Short version
===============================================================================

QTpLogger follows the same conventions as Tp-Qt4 and Qt itself.

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

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

QTpLogger uses the standard Qt4 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.

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

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

Patches can be announced at the kde-telepathy mailing list, for the moment.
We'll move to bugzilla very soon.

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