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
|
# Style
GNOME Calendar has a coding style based on GTK Coding Style, but with a few more
rules. Please read them carefully and, if in doubt, ask a maintainer for directions.
## General
The most important rule is: **see the surrounding code, and copy its style**.
Another rule that applies to function declarations is that all parameters are
aligned by the last '*'. There are plenty of examples below.
## Header (.h) files
* The '*' and the type come together, without any spaces in between.
* Function name starts at column 22.
* Parenthesis after function name is at column 66
* The last '*' in parameters are at column 86
As an example, this is how a function should look like:
```c
GcalManager* gcal_manager_foo_bar (GcalManager *self,
GError **example);
```
## Source code
The source file keeps an order of methods. The order will be as following:
1. GPL header
2. Structures
3. Function prototypes
4. G_DEFINE_TYPE()
5. Enums
6. Static variables
7. Auxiliary methods
8. Signal callbacks
9. Interface implementations
10. Parent class overrides
11. class_init and init
12. Public API
### Structures
The structures must have the last pointer asterisk at column 22. Non-pointer fields
start at column 23. For example:
```c
struct _GcalQuickAddPopover
{
GtkPopover parent;
GtkWidget *add_button;
GtkWidget *calendars_listbox;
GtkWidget *calendar_name_label;
GtkWidget *color_image;
GtkWidget *stack;
GtkWidget *summary_entry;
GtkWidget *title_label;
/* Internal data */
GDateTime *date_start;
GDateTime *date_end;
GtkWidget *selected_row;
gboolean clock_format_24h;
GcalManager *manager;
};
```
### Function Prototypes
Function prototypes must be formatted just like in header files.
### Auxiliary Methods
Auxiliary method names must have a verb in the dictionary form, and should always
perform an action over something. They don't have the gcal_foo prefix. For example:
```c
static void
do_something_on_data (Foo *data,
Bar *bar)
{
/* ... */
}
```
### Signal Callbacks
Signal callback names must have the name of the signal in the past. They don't have
the gcal_foo prefix as well, but have a _cb suffix. For example:
```c
static void
size_allocated_cb (GtkWidget *widget,
GtkAllocation *allocation,
gpointer user_data)
{
/* ... */
}
```
### Line Splitting
Line splitting works following the GTK code style, but legibility comes over above
all. If a function call looks unbalanced following the GTK style, it is fine to
slightly escape the rules.
For example, this feels extremelly unbalanced:
```c
foo_bar_do_somthing_sync (a,
1,
object,
data,
something
cancellable,
&error);
```
Notice the empty space before the arguments, and how empty and odd it looks. In
comparison, it will look better if written like this:
```c
foo_bar_do_somthing_sync (a, 1, object, data,
something
cancellable,
&error);
```
# Contributing guidelines
See CONTRIBUTING.md file for the contribution guidelines, and the Code of Conduct
that contributors are expected to follow.
|
