void function(int *n) { if (!n) { return; } ... }
Copyright © 2009-2016 Red Hat, Inc. Licensed under a Creative Commons Attribution-Share Alike 3.0 United States License (see http://creativecommons.org/licenses/by-sa/3.0/us/legalcode).
Use lower case and separate words using dashes (e.g., file-name.c, header.h).
Use standard file extension for C source and header files.
No more than 100 characters on a single line
Tabs are not allowed, use 4 spaces instead
Trailing white spaces are not allowed
Use Unix style line ending (i.e., LF)
New line (i.e., EOL) must be the last char in the file
Use right-hand comparison style.
Examples:
use (var == 7) instead of (7 == var)
use (function(var) > 7) instead of (7 < function(var))
Where possible prefer the usage of bool type to store boolean.
If not technically possible (ie libJPEG uses boolean while GLib uses gboolean) uses proper library type.
Constants should be consistent with the type used so true and false for bool type.
Use true, false and NULL instead of 1 and 0 in order to improve code readability.
To improve code readability, explicitly initialize variables that depend on default initialization with zero/null.
Comments that are prefixed with FIXME describe a bug that need to be fixed. Generally, it is not allowed to commit new code having FIXME comment. Committing FIXME is allowed only for existing bugs. Comments that are prefixed with TODO describe further features, optimization or code improvements, and they are allowed to be committed along with the relevant code.
Use it freely. ASSERT helps testing function arguments and function results validity. ASSERT helps detecting bugs and improve code readability and stability.
Apply function style to sizeof (i.e., use sizeof(x))
Use const keyword when applicable to improve code reliability and celerity.
Using goto is allowed in C code for error handling. In any other case it will be used only as a special exception.
Use defines for constant values for improving readability and ease of changes. Alternatively, use global const variables.
Try to split code to short functions, each having simple functionality, in order to improve code readability and re-usability. Prefix with inline short functions or functions that were splitted for readability reason.
Try to return immediately on if in places that can reduce indentation level.
Example:
prefer
void function(int *n) { if (!n) { return; } ... }
on
void function(int *n) { if (!n) { return; } else { ... } }
Don’t underestimate the importance of name choosing. Good names make the code more easy to understand and reduce the required level of code documentation. When choosing names, prefer long meaningful names over short vague name.
Variable and Function names - use lower case and separate words using underscore (e.g., sample_variable_name)
Structures, class and enum names - one or more words, each word start with upper case (e.g., Name, SampleStructName)
Defines and enum items names - uppercase words separated using underscores (e.g., NAME, SAMPLE_DEFINE_NAME)
In the code there are some common prefixes for types, Red and Spice. As a basic rule Spice refers to types in the public external headers while Red is used for internal types.
ccc CursorChannelClient
dc DisplayChannel
dcc DisplayChannelClient
dpi drawable pipe item
rcc RedChannelClient
sif spice interface
sin spice instance
Keep optimization to fast path code. Prefer safe, clear and easy to maintain coding for code that is not on the fast path.
Use spacing for improving code readability.
for (i = 0; i < 10; ++i) { some_func(var, i * i + *ptr, &var, sizeof(var)); }
No spaces between function name to left bracket.
Curly bracket start on new line.
Functions must be padded with empty lines on both sides
void function(type1 arg1, type2 arg2, type2 arg3) { ... }
In case of a new line in arguments list, align it to the first argument type.
void function(type1 arg1, type2 arg2, type3 arg3)
Or
void function(type1 arg1, type2 arg2, type3 arg3)
New line is acceptable in arguments list and before function name, like
void function(type1 arg1, type2 arg2, type3 arg3)
Add space after a branch keyword and after the right bracket.
Curly bracket starts on the same line the branch starts.
Place curly brackets after all control flow constructs even where optional. This convention reduces branching bugs that are difficult to detect. It also makes it easier to add logging messages during debugging since it eliminates the need to add the brackets.
if (condition) { ... } else if (condition) { ... } else { ... }
In case of long condition statement, prefer having additional temporary variable over multiple line condition statement.
In case of new line in condition statement.
if (long_name && very_long_name && very_long || var_name) {
or indent under the round bracket using spaces
if (long_name && very_long_name && long_name || var_name) {
Break function arguments list in long condition statement according to Function Indentation section.
while (condition) { ... } do { ... } while (condition); for (i = x; i < y; i++) { ... } switch (x) { case A: { ... break; } case B: ... ... break; default: ... }
struct StructName { type1 name1; type2 name2; ... }; enum { A, B, C = 10, D, }; union { type1 name1; type2 name2; ... } u;
Use one space no tabs and no vertical alignment.
long var_name_1 = 7; int var_name_2 = 1111l; unsigned long long_var_name_1 = 666; char long_var_name_1 = 'a'; void f1(int a, char ch); unsigned long f2(int a, char ch);
#define MACRO_NAME(a, b, c) { \ int ab = a + c; \ int ac = a + b; \ int bc = b + c; \ f(ab, ac, bc); \ }
char *array[] = { "item_1", "item_2", "item_3", };
Headers should be included in this order
#include <system_headers.h> #include <no_spice_no_system_libraries.h> #include <spice_protocol.h> #include <spice_common.h> #include "spice_server.h"
(note the empty line between no spice-server and spice-server headers)
Also in source (no header) files you must include config.h at the beginning so should start (beside comments and copyright) with
#ifdef HAVE_CONFIG_H #include <config.h> #endif #include <system_headers.h> #include <no_spice_no_system_libraries.h> #include <spice_protocol.h> #include <spice_common.h> #include "spice_server.h"