README: Elaborate coding style and commit message guidelines
Spell out some conventions used in the README. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1521
This commit is contained in:
parent
5ab187da70
commit
8fb30e6ec5
50
README.md
50
README.md
@ -29,17 +29,55 @@ To contribute, open merge requests at https://gitlab.gnome.org/GNOME/mutter.
|
||||
It can be useful to look at the documentation available at the
|
||||
[Wiki](https://gitlab.gnome.org/GNOME/mutter/-/wikis/home).
|
||||
|
||||
## Coding style and conventions
|
||||
|
||||
The coding style used is primarily the GNU flavor of the [GNOME coding
|
||||
style](https://developer.gnome.org/programming-guidelines/stable/c-coding-style.html.en)
|
||||
with some minor additions such as preferring regular C types and
|
||||
`stdint.h` types over GLib fundamental types, except for gboolean, and
|
||||
guint/gulong for GSource ids and signal handler ids. There is also a soft
|
||||
80 character line limit. However, in general, look at the file you're
|
||||
editing for inspiration.
|
||||
with some additions:
|
||||
|
||||
- Use regular C types and `stdint.h` types instead of GLib fundamental
|
||||
types, except for `gboolean`, and `guint`/`gulong` for GSource ids and
|
||||
signal handler ids. That means e.g. `uint64_t` instead of `guint64`, `int`
|
||||
instead of `gint`, `unsigned int` instead of `guint` if unsignedness
|
||||
is of importance, `uint8_t` instead of `guchar`, and so on.
|
||||
|
||||
- Try to to limit line length to 80 characters, although it's not a
|
||||
strict limit.
|
||||
|
||||
- Usage of g_autofree and g_autoptr are encouraged. The style used is
|
||||
|
||||
```c
|
||||
g_autofree char *text = NULL;
|
||||
g_autoptr (MetaSomeThing) thing = NULL;
|
||||
|
||||
text = g_strdup_printf ("The text: %d", a_number);
|
||||
thing = g_object_new (META_TYPE_SOME_THING,
|
||||
"text", text,
|
||||
NULL);
|
||||
thinger_use_thing (rocket, thing);
|
||||
```
|
||||
|
||||
- Declare variables at the top of the block they are used, but avoid
|
||||
non-trivial logic among variable declarations. Non-trivial logic can be
|
||||
getting a pointer that may be `NULL`, any kind of math, or anything
|
||||
that may have side effects.
|
||||
|
||||
- Instead of boolean arguments in functions, prefer enums or flags when
|
||||
they're more expressive.
|
||||
|
||||
- Use `g_new0()` etc instead of `g_slice_new0()`.
|
||||
|
||||
- Initialize and assign floating point variables (i.e. `float` or
|
||||
`double`) using the form `floating_point = 3.14159` or `ratio = 2.0`.
|
||||
|
||||
## Git messages
|
||||
|
||||
Commit messages should follow the [GNOME commit message
|
||||
guidelines](https://wiki.gnome.org/Git/CommitMessages). We require an URL
|
||||
to either an issue or a merge request in each commit.
|
||||
to either an issue or a merge request in each commit. Try to always prefix
|
||||
commit subjects with a relevant topic, such as `compositor:` or
|
||||
`clutter/actor:`, and it's always better to write too much in the commit
|
||||
message body than too little.
|
||||
|
||||
## License
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user