summaryrefslogtreecommitdiff
path: root/CODING_STYLE
blob: 0b851c05335a5f6c4635657217fdceb546265251 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
Pixman coding style.

The pixman coding style is close to cairo's. There is one exception
though: braces go on their own line, rather than on the line of the
if/while/for:

	if (condition)
	{
	    do_something();
	    do_something_else();
	}

not

	if (condition) {
	    do_something();
	    do_something_else();
        }

Specific guidelines:

Indentation
===========

Each new level is indented four spaces:

	if (condition)
	    do_something();

This may be achieved with space characters or with a combination of
tab characters and space characters. Tab characters are interpreted as

	Advance to the next column which is a multiple of 8.

Names
=====

In all names, words are separated with underscores. Do not use
CamelCase for any names.

Macros have ALL_CAPITAL_NAMES

Type names are in lower case and end with "_t". For example
pixman_image_t.

Labels, functions and variables have lower case names.

Braces
======

Braces always go on their own line:

	if (condition)
	{
	    do_this ();
	    do_that ();
	}
	else
	{
	    do_the_other ();
	}

Rules for braces and substatements of if/while/for/do:

* If a substatement spans multiple lines, then there must be braces
  around it.

* If the condition of an if/while/for spans multiple lines, then 
  braces must be used for the substatements.

* If one substatement of an if statement has braces, then the other
  must too.

* Otherwise, don't add braces.

Whitespace
==========

Separate logically distinct chunks with a single newline. This
obviously applies between functions, but also applies within a
function or block or structure definition.

Use a newline after a block of variable declarations.

Use a single space before a left parenthesis, except where the
standard will not allow it, (eg. when defining a parameterized macro).

Don't eliminate newlines just because things would still fit on one
line. This breaks the expected visual structure of the code making it
much harder to read and understand:

	if (condition) foo (); else bar ();	/* Yuck! */

Do eliminate trailing whitespace (space or tab characters) on any
line. Also, avoid putting initial or final blank lines into any file,
and never use multiple blank lines instead of a single blank line.

Do enable the default git pre-commit hook that detect trailing
whitespace for you and help you to avoid corrupting cairo's tree with
it. Do that as follows:

	chmod a+x .git/hooks/pre-commit

You might also find the git-stripspace utility helpful which acts as a
filter to remove trailing whitespace as well as initial, final, and
duplicate blank lines.

Break up long lines (> ~80 characters) and use whitespace to align
things nicely. For example the arguments in a long list to a function
call should all be aligned with each other:

	align_function_arguments (argument_the_first,
				  argument_the_second,
				  argument_the_third);

Function prototypes and definitions can be formatted in two ways. If
all parameters fit naturally on one line, then format them on one
line:


	int
	some_function (int x, int y, int z)
	{
	}

If the parameters do not fit on one line, then whitespace should be
inserted between the parameter types and names so that the names are
aligned:

	void
	align_parameter_names_in_prototypes (const char *char_star_arg,
					     int	 int_arg,
					     double	*double_star_arg,
					     double	 double_arg);

The return type and associated specifiers and qualifiers should always
be on a line above the function, so that the function name is flush
left.


Mode lines
==========

So given the rules above, what is the best way to simplify one's life as
a code monkey? Get your editor to do most of the tedious work of
beautifying your code!

As a reward for reading this far, here are some mode lines for the more
popular editors:
/*
 * vim:sw=4:sts=4:ts=8:tw=78:fo=tcroq:cindent:cino=\:0,(0
 * vim:isk=a-z,A-Z,48-57,_,.,-,>
 */