File: HACKING.md

package info (click to toggle)
gnome-todo 3.28.1-2
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, sid
  • size: 3,668 kB
  • sloc: ansic: 17,775; python: 198; xml: 113; makefile: 6
file content (127 lines) | stat: -rw-r--r-- 3,285 bytes parent folder | download | duplicates (2)
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
# Style

GNOME To Do 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
GtdManager*          gtd_manager_foo_bar                         (GtdManager         *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 _GtdTimer
{
  GtdObject           parent;

  guint               update_timeout_id;

  GDateTime          *current_day;

  GDBusProxy         *logind;
  GCancellable       *cancellable;
};
```

### 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 `gtd_class_name` 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 `gtd_class_name` 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 CONTRIBUTIONS.md file for the contribution guidelines, and the Code of Conduct
that contributors are expected to follow.