4
The pixman coding style is close to cairo's with one exception: braces
5
go on their own line, rather than on the line of the if/while/for:
25
Each new level is indented four spaces:
30
This may be achieved with space characters or with a combination of
31
tab characters and space characters. Tab characters are interpreted as
33
Advance to the next column which is a multiple of 8.
39
In all names, words are separated with underscores. Do not use
40
CamelCase for any names.
42
Macros have ALL_CAPITAL_NAMES
44
Type names are in lower case and end with "_t". For example
47
Labels, functions and variables have lower case names.
53
Braces always go on their own line:
65
Rules for braces and substatements of if/while/for/do:
67
* If a substatement spans multiple lines, then there must be braces
70
* If the condition of an if/while/for spans multiple lines, then
71
braces must be used for the substatements.
73
* If one substatement of an if statement has braces, then the other
76
* Otherwise, don't add braces.
82
For comments either like this:
84
/* One line comment */
88
/* This is a multi-line comment
90
* It extends over multiple lines
93
Generally comments should say things that aren't clear from the code
94
itself. If too many comments say obvious things, then people will just
95
stop reading all comments, including the good ones.
101
* Put a single space after commas
103
* Put spaces around arithmetic operators such a +, -, *, /:
109
* Do not put spaces after the address-of operator, the * when used as
110
a pointer derefernce or the ! and ~ operators:
120
* Break up long lines (> ~80 characters) and use whitespace to align
121
things nicely. This is one way:
123
some_very_long_function name (
124
implementation, op, src, mask, dest,
125
src_x, src_y, mask_x, mask_y, dest_x, dest_y,
130
some_very_long_function_name (implementation, op,
137
* Separate logically distinct chunks with a single newline. This
138
obviously applies between functions, but also applies within a
139
function or block or structure definition.
141
* Use a newline after a block of variable declarations.
143
* Use a single space before a left parenthesis, except where the
144
standard will not allow it, (eg. when defining a parameterized macro).
146
* Don't eliminate newlines just because things would still fit on one
147
line. This breaks the expected visual structure of the code making
148
it much harder to read and understand:
150
if (condition) foo (); else bar (); /* Yuck! */
156
Function definitions should take the following form:
159
my_function (int argument)
164
If all the parameters to a function fit naturally on one line, format
165
them that way. Otherwise, put one argument on each line, adding
166
whitespace so that the parameter names are aligned with each other.
168
I.e., do either this:
171
short_arguments (const char *str, int x, int y, int z)
178
long_arguments (const char *char_star_arg,
180
double *double_star_arg,
189
Given the rules above, what is the best way to simplify one's life as
190
a code monkey? Get your editor to do most of the tedious work of
191
beautifying your code!
193
As a reward for reading this far, here are some mode lines for the more
196
* vim:sw=4:sts=4:ts=8:tw=78:fo=tcroq:cindent:cino=\:0,(0
197
* vim:isk=a-z,A-Z,48-57,_,.,-,>