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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
HACKING GCR and GCK libraries
BUILD OPTIONS
---------------
Build options for developers:
--enable-strict: Build with -Werror, disable deprecations, and fatal warnings
--enable-debug: Turn off compiler optimization
--disable-debug: Turn off all debug options and output.
--enable-coverage: Build coverage, use 'make coverage' for summary.
PATCHES
----------
Patches should be submitted to bugzilla:
http://bugzilla.gnome.org/enter_bug.cgi?product=gnome-keyring&component=gcr
The gnome-keyring mailing list is:
gnome-keyring-list@gnome.org
egg
Various bits of code shared with other modules
gck
A public library for accessing PKCS#11 modules.
gcr
A public library for bits of crypto UI and parsing etc...
schema
Desktop settings schemas for crypto stuff
testing
Testing CA, gnupg and other mock setups
----------------------------------------------------------------------------------
CODING STYLE
----------------------------------------------------------------------------------
Our coding style is very similar to the linux coding style:
http://lxr.linux.no/linux/Documentation/CodingStyle
Summary below. Differences from Linux coding style are marked with a plus
instead of an asterisk:
+ Space between function name and parentheses.
my_function_call (arg1, arg2);
* Braces on the same line as conditional with spaces around braces:
if (test) {
do_y ();
do_z ();
}
switch (value) {
case CONSTANT:
do_z ();
break;
default:
break;
}
* Braces around functions on a separate line from function name,
return value on a separate line, arguments on separate lines.
static void
my_special_function (int arg1,
int arg2)
{
/* body of function */
}
* Don't use braces unnecessarily:
if (test)
do_this_thing ();
* But use braces here, when one section has more than a line:
if (test) {
do_this_thing ();
} else {
do_other_thing ();
smile_nicely ();
}
* Use of tabs for 8 char indent.
------->if (test) {
------->------->Value;
------->------->Value;
------->}
* No trailing whitespace on lines. Git will warn you about this.
Please enforce it like so (in gnome-keyring checkout):
$ cp -ipv .git/hooks/pre-commit.sample .git/hooks/pre-commit
* The '*' in a pointer declaraction belongs with the variable name:
char *name;
+ Extra long wrapped lines should wrap to function opening brace
using spaces past indentation point.
------>my_function_call ("this is a very long argument here",
------> "wrapped argument is indented with spaces");
* Function names are in lower case with _ separators.
this_is_a_long_function_name ();
* Constants are all in upper case with _ separators.
THIS_IS_A_CONSTANT
+ Structures should be typedefed to avoid saying 'struct' and names
are CamelCase:
ThisIsAStruct
* One line comments should look like:
/* This is a one line comment */
* Multi line comments should look like:
/*
* This is a multiline comment.
* And it has a useless second line.
*/
When in doubt adapt to the style of the code around your patch.
|
