1 GENIVI Boot Manager Coding Style
2 ================================
4 This document intends to give information about the coding style to be
5 used when contributing code to the GENIVI Boot Manager. It does not
6 claim to be complete. Parts of it are taken or inspired from the Clutter
9 In the following, the most important requirements for writing consistent
10 code for the GENIVI Boot Manager are explained.
13 * Copyright and License Header
16 * Indentation and Braces
17 * Functions and Braces
19 * Variable Declarations
23 * Loops and Loop Termination
26 Copyright and License Header
27 ============================
29 In all source files, add the following copyright and license header at
32 /* vi:set et ai sw=2 sts=2 ts=2: */
34 * Copyright (c) 2012 GENIVI.
36 * This Source Code Form is subject to the terms of the Mozilla Public
37 * License, v. 2.0. If a copy of the MPL was not distributed with this
38 * file, You can obtain one at http://mozilla.org/MPL/2.0/.
45 The maximum line width for source files is 90 characters. This limit may
46 be exceeded when there is no way around it. Accepted ways to wrap long
47 lines caused by function calls are
49 result = some_function_with_a_very_long_name (first_parameter,
55 long_result_variable =
56 some_function_with_a_very_long_name (first_parameter,
60 where the result variable name is too long to fit the function call
61 into the 90 characters limit even when wrapping the parameters.
63 Do not separate the function name from its arguments like this:
66 some_function_with_a_long_name
67 (long_argument_name1, long_argument_name2);
69 Instead, consider using shorter variable names as aliases:
72 short1 = long_argument_name1;
73 short2 = long_argument_name2;
74 some_function_with_a_long_name (short1, short2);
76 The line width limit of 90 characters does not apply to header files.
77 However the alignment and parameter indentation rules explained in the
78 section "Functions and Braces" still apply to header files.
84 Always insert a space before a parenthesis but never after or
85 between the opening or closing parenthesis and a parameter.
89 foo (argument1, argument2);
93 foo(argument1, argument2);
97 foo ( argument1, argument 2 );
100 Indentation and Braces
101 ======================
103 Use spaces only, tabs are not allowed. The indentation for each level is
104 2 spaces in addition to the previous level. Braces add another level of
105 indentation. Valid indentations and uses of braces are:
107 Single-line statements:
111 single_line_statement ();
119 another_statement ();
122 Multiple and single statements:
128 another_statement ();
132 one_more_statement ();
159 do_something_else ();
162 do_whatever_you_need_to_do ();
184 case FOO: do_something ();
196 Nested if statements:
201 /* here the same rules as on the top level apply again */
202 if (another_condition)
204 else if (yet_another_condition)
205 another_single_statement ();
208 Do not put curly braces into the same line as the condition:
215 Do not asymmetrically use and not use braces:
220 /* multiple statements */
225 If there are multiple conditions in a single if statement spread across
226 more than one line, always use curly braces:
232 /* multiple or single statement(s) */
239 Braces in function definitions are not indented. Parameters are to be
240 wrapped and aligned so that the end results looks like this:
242 Function declarations:
245 static gchar *some_type_your_function (SomeType *object,
246 int another parameter,
247 gchar **and_another_one);
248 static gboolean some_type_some_longer_function_name (SomeType *object);
250 Function definitions:
254 some_type_your_function (SomeType *object,
255 int another_parameter,
256 gchar **and_another_one)
263 Do not declare functions like this:
266 static gchar *some_type_your_function (SomeType *object,
267 int another parameter,
268 gchar **and_another_one);
269 static gboolean some_type_some_longer_function_name (SomeType *object);
274 static gchar *some_type_your_function (SomeType *object, int another parameter, gchar **and_another_one);
275 static gboolean some_type_some_longer_function_name (SomeType *object);
281 Between declarations of groups of structs, enums, functions, static
282 variables and macros there have to be three empty lines to make the
283 different items easier to spot and distinguish. There also have to be
284 three empty lines between function definitions.
286 Also, when declaring data structures, use newlines to separate logical
287 sections of member variables:
289 struct _LucHandlerService
291 /* Current LUC content */
292 GHashTable *current_content;
295 /* NSM shutdown consumer */
296 ShutdownConsumer *shutdown_consumer;
298 /* protection against threads */
303 Variable Declarations
304 =====================
306 Variables may only be declared at the top of a function. Variable
307 declarations in blocks (code surrounded by braces) are not allowed.
309 Declarations follow special alignment and sorting rules. The sorting
310 order of declarations is determined by:
312 1. number of characters of the variable type
313 2. ascending alphabetical order of the type (case-insensitive)
314 3. ascending alphabetical order of the variable name
316 Here is an example of how a variable declaration sequence has to
319 GbmgrLegacyAppHandlerService *service;
320 NSMShutdownConsumer *consumer;
321 const gchar *object_name;
330 In order to make it easier to detect broken code paths, assertions in
331 the form of g_return_if_fail() and g_return_val_if_fail() statements are
332 used in almost all methods. When implementing new methods in your code,
333 please make sure to check the input parameters for type incompatiblities
334 or memory corruption.
340 Do not check boolean values for equality like this:
343 if (condition == TRUE)
346 Instead, just do it like this:
352 Be explicit when checking pointers however:
355 if (some_pointer == NULL)
359 if (some_pointer != NULL)
362 Do not simply do it like this:
368 If you have so many conditions in an if statement that you need to split
369 them up into multiple lines, the logical operatiors should always be
370 placed at the beginning of the line, like this:
380 Don't place the logical operators at the end of the line:
394 Header files should always include the following code in addition to the
395 license header (example for gbmgr-data-structure.h):
397 #ifndef __GBMGR_DATA_STRUCTURE_H__
398 #define __GBMGR_DATA_STRUCTURE_H__
400 #include <something-that-also-includes-glib-object.h>
408 #endif /* !__GBMGR_DATA_STRUCTURE_H__ */
412 Loops and Loop Termination
413 ==========================
415 When writing loops, try to avoid break statements. Instead of breaking
416 on some condition move the condition into the loop header to make more
417 clear when the loop is supposed to be terminated.
422 for (n = 0; n < some_value; ++n)
424 if (some_other_condition)
433 for (n = 0; !some_other_condition && n < some_value; ++n)
438 If the loop header exceeds the 90 character limit per line, split it up
439 into multiple lines (in which case you are required to add curly braces
444 !some_other_condition && n < some_value;
450 Try to avoid while loops where you can. Some GLib data structures
451 such as iterators encourage the use of while loops. In those cases it's
452 ok not to use for loops.