File: guidelines.txt

package info (click to toggle)
rosegarden4 1.0-1
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 22,344 kB
  • ctags: 14,022
  • sloc: cpp: 131,139; sh: 9,429; perl: 2,620; xml: 2,231; makefile: 607; python: 374; ansic: 339; ruby: 173; php: 2
file content (61 lines) | stat: -rw-r--r-- 1,986 bytes parent folder | download
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

Rosegarden-4 Coding Guidelines
==============================

Rosegarden-4 is written in C++ and makes fairly full use of modern
features of the language and of the standard library.  We definitely
aim to write C++ rather than C-with-classes or a-better-C.

Code should be readable and well-presented.  We have guidelines for
coding style, and try to follow them although there are some misses
:-). If you want to contribute, please stick as close to these as you
can.


Style and naming conventions
----------------------------

 * indent 4 spaces at a time

 * data member names begin with 'm_'.

 * names use internal capitalization (HereIsAnExample)

 * class names begin with an upper case (class MyClass)

 * method and variable names names begin with a lower case (int myMethod())

 * brace placement is rather liberal

 * classes should either be in the Rosegarden namespace or 
   be easily identifiable as part of the Rosegarden code
   (i.e. no QClasses or KClasses please)

Language issues
---------------

 * malloc()/free() and C-style arrays (that includes char*) are
   explicitely forbidden except when there are no alternatives
   (e.g. some external API requires it).

 * avoid C-style casts.  The only time they're okay is to shut up
   signed/unsigned or int/double conversion warnings

 * when given the choice, prefer STL containers to Qt ones

 * use std::string whenever possible (e.g. in core), QString
   only when you need to deal with Qt widgets, or need some of
   its features (like regexps).

 * public data members are forbidden except in very trivial
   classes. Provide accessors, and name them getXXX/setXXX.

 * use javadoc-style comments to document the purpose of a
   method within the class declaration.

 * use 'protected' instead of 'private'.

 * and rather obviously, stick with the layout existing in a file
   when you edit it (e.g. for brace indentation) and maintain the
   style already present in a library when adding files to it.