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
|
GNOME Boxes Coding Style
========================
The coding style to respect in this project is very similar to most
Vala projects. In particular, the following rules are largely adapted
from the Rygel Coding Style.
* 4-spaces (and not tabs) for indentation.
* ''Prefer'' lines of less than <= 120 columns
* 1-space between function name and braces (both calls and signature
declarations)
* Avoid the use of 'this' keyword:
* If function signature/call fits in a single line, do not break it
into multiple lines.
* For methods/functions that take variable argument tuples, all the
first elements of tuples are indented normally with the subsequent
elements of each tuple indented 4-space more. Like this:
action.get ("ObjectID",
typeof (string),
out this.object_id,
"Filter",
typeof (string),
out this.filter,
"StartingIndex",
typeof (uint),
out this.index,
"RequestedCount",
typeof (uint),
out this.requested_count,
"SortCriteria",
typeof (string),
out this.sort_criteria);
* ''Prefer'' descriptive names over abbreviations (unless well-known)
& shortening of names. E.g discoverer over disco.
* Use 'var' in variable declarations wherever possible.
* Use 'as' to cast wherever possible.
* Single statments inside if/else must not be enclosed by '{}'.
* The more you provide docs in comments, but at the same time avoid
over-documenting. Here is an example of useless comment:
// Fetch the document
fetch_the_document ();
* Each class should go in a separate .vala file & named according to
the class in it. E.g Boxes.SpiceDisplay class should go under
spice-display.vala.
* Avoid putting more than 3 'using' statements in each .vala file. If
you feel you need to use more, perhaps you should consider
refactoring (Move some of the code to a separate class).
* Declare the namespace(s) of the class/errordomain with the
class/errordomain itself. Like this:
private class Boxes.Hello {
...
};
* Prefer 'foreach' over 'for'.
* Add a newline to break the code in logical pieces
* Add a newline before each return, throw, break etc. if it
is not the only statement in that block
if (condition_applies ()) {
do_something ();
return false;
}
if (other_condition_applies ())
return true;
Except for the break in a switch:
switch (val) {
case 1:
debug ("case 1");
do_one ();
break;
default:
...
}
* If a function returns several equally important values, they should
all be given as out arguments. IOW, prefer this:
void get_a_and_b (out string a, out string b)
rather than the un-even, string get_a_and_b (out b)
|
