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,_,.,-,>