summaryrefslogtreecommitdiffstats
path: root/docs/HACKING.md
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 17:45:20 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 17:45:20 +0000
commitae1c76ff830d146d41e88d6fba724c0a54bce868 (patch)
tree3c354bec95af07be35fc71a4b738268496f1a1c4 /docs/HACKING.md
parentInitial commit. (diff)
downloadgnome-control-center-ae1c76ff830d146d41e88d6fba724c0a54bce868.tar.xz
gnome-control-center-ae1c76ff830d146d41e88d6fba724c0a54bce868.zip
Adding upstream version 1:43.6.upstream/1%43.6upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to '')
-rw-r--r--docs/HACKING.md291
1 files changed, 291 insertions, 0 deletions
diff --git a/docs/HACKING.md b/docs/HACKING.md
new file mode 100644
index 0000000..a60e206
--- /dev/null
+++ b/docs/HACKING.md
@@ -0,0 +1,291 @@
+# Style
+
+GNOME Settings 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**.
+
+That said, GNOME Settings assumes:
+
+ * 2 spaces of indentation
+ * 120 columns of line width
+ * Newline before `{`
+
+Another rule that applies to function declarations is that all parameters are
+aligned by the last '*'. There are plenty of examples below.
+
+## Comments
+
+Comment blocks should be formatted as following:
+
+```c
+/* Single line comment */
+
+/* Multiline comments start at the first line of the comment block,
+ * but have the closing slash a line after. Every line starts with
+ * an asterisk that is aligned with every the rest of the block.
+ */
+```
+
+## Conditionals
+
+Conditionals should either be all in one line, or one per line. Newlines inside
+conditionals are aligned by the last parenthesis.
+
+
+Some examples below:
+
+```c
+// Single line if
+if (a || b || (c && d))
+ return;
+
+// Multiline if with nested parenthesis
+if (long_boolean_variable_used_in_this_condition_a ||
+ long_boolean_variable_used_in_this_condition_b ||
+ (long_boolean_variable_used_in_this_condition_c &&
+ long_boolean_variable_used_in_this_condition_d))
+ {
+ return;
+ }
+
+// Another single line example with do {} while (...)
+do
+ {
+ /* something */
+ }
+while (a || b || (c && d));
+```
+
+## Structs and Enums
+
+Structures and enums are formatted as following:
+
+```c
+struct _FooBar
+{
+ guint32 field_one;
+ gchar *text;
+};
+
+typedef struct
+{
+ FooParent parent;
+
+ guint32 field_one;
+ gchar *text;
+
+ struct
+ {
+ CustomType *something;
+ guint something_else;
+ } inner_struct;
+
+ gboolean flag : 1;
+} FooBar;
+
+enum
+{
+ FIRST,
+ SECOND,
+ LAST,
+};
+
+typedef enum
+{
+ FOO_BAR_FIRST,
+ FOO_BAR_SECOND,
+ FOO_BAR_LAST,
+} FooEnumBar;
+```
+
+## Header (.h) files
+
+It is organized by the following structure:
+
+ 1. GPL header
+ 2. Local includes
+ 3. System includes
+ 4. `G_BEGIN_DECLS`
+ 5. `#defines`
+ 6. `G_DECLARE_{FINAL,DERIVABLE}_TYPE`
+ 7. Public API
+ 8. `G_END_DECLS`
+
+The following style rules apply:
+
+ * The '*' and the type come together, without any spaces in between.
+ * Function names are aligned by the widest return value.
+ * Parenthesis after function name is aligned by the widest function name
+ * The last '*' in parameters are aligned by the widest parameter type
+ * No new line at the end of the file
+
+As an example, this is how a header file should look like (extracted from
+the `cc-object-storage.h` file):
+
+```c
+/* cc-object-storage.h
+ *
+ * Copyright 2018 Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#pragma once
+
+#include <glib-object.h>
+#include <gio/gio.h>
+
+G_BEGIN_DECLS
+
+/* Default storage keys */
+#define CC_OBJECT_NMCLIENT "CcObjectStorage::nm-client"
+
+
+#define CC_TYPE_OBJECT_STORAGE (cc_object_storage_get_type())
+
+G_DECLARE_FINAL_TYPE (CcObjectStorage, cc_object_storage, CC, OBJECT_STORAGE, GObject)
+
+gboolean cc_object_storage_has_object (const gchar *key);
+
+void cc_object_storage_add_object (const gchar *key,
+ gpointer object);
+
+gpointer cc_object_storage_get_object (const gchar *key);
+
+gpointer cc_object_storage_create_dbus_proxy_sync (GBusType bus_type,
+ GDBusProxyFlags flags,
+ const gchar *name,
+ const gchar *path,
+ const gchar *interface,
+ GCancellable *cancellable,
+ GError **error);
+
+void cc_object_storage_create_dbus_proxy (GBusType bus_type,
+ GDBusProxyFlags flags,
+ const gchar *name,
+ const gchar *path,
+ const gchar *interface,
+ GCancellable *cancellable,
+ GAsyncReadyCallback callback,
+ gpointer user_data);
+
+G_END_DECLS
+```
+
+## 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. Callbacks
+ 9. Interface implementations
+ 10. Parent class overrides
+ 11. class_init and init
+ 12. Public API
+
+### Structures
+
+The structures must have the first pointer asterisk aligned one space after the
+widest type name. For example:
+
+```c
+typedef struct
+{
+ GBusType bus_type;
+ GDBusProxyFlags flags;
+ gchar *name;
+ gchar *path;
+ gchar *interface;
+ gboolean cached;
+} TaskData;
+
+```
+
+### 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 `cc_` prefix. For example:
+
+```c
+static void
+execute_something_on_data (Foo *data,
+ Bar *bar)
+{
+ /* ... */
+}
+```
+
+### Callbacks
+
+ * Callbacks always have the `_cb` suffix
+ * Signal callbacks always have the `on_<object_name>` prefix
+ * Callback names must have the name of the signal in the past
+
+For example:
+
+```c
+static void
+on_foo_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. \ No newline at end of file