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:
Jonas Ådahl 2020-10-23 20:47:01 +02:00
parent 5ab187da70
commit 8fb30e6ec5

View File

@ -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 It can be useful to look at the documentation available at the
[Wiki](https://gitlab.gnome.org/GNOME/mutter/-/wikis/home). [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 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) style](https://developer.gnome.org/programming-guidelines/stable/c-coding-style.html.en)
with some minor additions such as preferring regular C types and with some additions:
`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 - Use regular C types and `stdint.h` types instead of GLib fundamental
80 character line limit. However, in general, look at the file you're types, except for `gboolean`, and `guint`/`gulong` for GSource ids and
editing for inspiration. 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 Commit messages should follow the [GNOME commit message
guidelines](https://wiki.gnome.org/Git/CommitMessages). We require an URL 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 ## License