1 1.1 mrg Pixman coding style. 2 1.1 mrg ==================== 3 1.1 mrg 4 1.1 mrg The pixman coding style is close to cairo's with one exception: braces 5 1.1 mrg go on their own line, rather than on the line of the if/while/for: 6 1.1 mrg 7 1.1 mrg if (condition) 8 1.1 mrg { 9 1.1 mrg do_something(); 10 1.1 mrg do_something_else(); 11 1.1 mrg } 12 1.1 mrg 13 1.1 mrg not 14 1.1 mrg 15 1.1 mrg if (condition) { 16 1.1 mrg do_something(); 17 1.1 mrg do_something_else(); 18 1.1 mrg } 19 1.1 mrg 20 1.1 mrg 21 1.1 mrg 22 1.1 mrg Indentation 23 1.1 mrg =========== 24 1.1 mrg 25 1.1 mrg Each new level is indented four spaces: 26 1.1 mrg 27 1.1 mrg if (condition) 28 1.1 mrg do_something(); 29 1.1 mrg 30 1.1 mrg This may be achieved with space characters or with a combination of 31 1.1 mrg tab characters and space characters. Tab characters are interpreted as 32 1.1 mrg 33 1.1 mrg Advance to the next column which is a multiple of 8. 34 1.1 mrg 35 1.1 mrg 36 1.1 mrg Names 37 1.1 mrg ===== 38 1.1 mrg 39 1.1 mrg In all names, words are separated with underscores. Do not use 40 1.1 mrg CamelCase for any names. 41 1.1 mrg 42 1.1 mrg Macros have ALL_CAPITAL_NAMES 43 1.1 mrg 44 1.1 mrg Type names are in lower case and end with "_t". For example 45 1.1 mrg pixman_image_t. 46 1.1 mrg 47 1.1 mrg Labels, functions and variables have lower case names. 48 1.1 mrg 49 1.1 mrg 50 1.1 mrg Braces 51 1.1 mrg ====== 52 1.1 mrg 53 1.1 mrg Braces always go on their own line: 54 1.1 mrg 55 1.1 mrg if (condition) 56 1.1 mrg { 57 1.1 mrg do_this (); 58 1.1 mrg do_that (); 59 1.1 mrg } 60 1.1 mrg else 61 1.1 mrg { 62 1.1 mrg do_the_other (); 63 1.1 mrg } 64 1.1 mrg 65 1.1 mrg Rules for braces and substatements of if/while/for/do: 66 1.1 mrg 67 1.1 mrg * If a substatement spans multiple lines, then there must be braces 68 1.1 mrg around it. 69 1.1 mrg 70 1.1 mrg * If the condition of an if/while/for spans multiple lines, then 71 1.1 mrg braces must be used for the substatements. 72 1.1 mrg 73 1.1 mrg * If one substatement of an if statement has braces, then the other 74 1.1 mrg must too. 75 1.1 mrg 76 1.1 mrg * Otherwise, don't add braces. 77 1.1 mrg 78 1.1 mrg 79 1.1 mrg Comments 80 1.1 mrg ======== 81 1.1 mrg 82 1.1 mrg For comments either like this: 83 1.1 mrg 84 1.1 mrg /* One line comment */ 85 1.1 mrg 86 1.1 mrg or like this: 87 1.1 mrg 88 1.1 mrg /* This is a multi-line comment 89 1.1 mrg * 90 1.1 mrg * It extends over multiple lines 91 1.1 mrg */ 92 1.1 mrg 93 1.1 mrg Generally comments should say things that aren't clear from the code 94 1.1 mrg itself. If too many comments say obvious things, then people will just 95 1.1 mrg stop reading all comments, including the good ones. 96 1.1 mrg 97 1.1 mrg 98 1.1 mrg Whitespace 99 1.1 mrg ========== 100 1.1 mrg 101 1.1 mrg * Put a single space after commas 102 1.1 mrg 103 1.1 mrg * Put spaces around arithmetic operators such a +, -, *, /: 104 1.1 mrg 105 1.1 mrg y * stride + x 106 1.1 mrg 107 1.1 mrg x / unit_x 108 1.1 mrg 109 1.1 mrg * Do not put spaces after the address-of operator, the * when used as 110 1.1 mrg a pointer derefernce or the ! and ~ operators: 111 1.1 mrg 112 1.1 mrg &foo; 113 1.1 mrg 114 1.1 mrg ~0x00000000 115 1.1 mrg 116 1.1 mrg !condition 117 1.1 mrg 118 1.1 mrg *result = 100 119 1.1 mrg 120 1.1 mrg * Break up long lines (> ~80 characters) and use whitespace to align 121 1.1 mrg things nicely. This is one way: 122 1.1 mrg 123 1.1 mrg some_very_long_function name ( 124 1.1 mrg implementation, op, src, mask, dest, 125 1.1 mrg src_x, src_y, mask_x, mask_y, dest_x, dest_y, 126 1.1 mrg width, height); 127 1.1 mrg 128 1.1 mrg This is another: 129 1.1 mrg 130 1.1 mrg some_very_long_function_name (implementation, op, 131 1.1 mrg src, mask, dest, 132 1.1 mrg src_x, src_y, 133 1.1 mrg mask_x, mask_y, 134 1.1 mrg dest_x, dest_y, 135 1.1 mrg width, height); 136 1.1 mrg 137 1.1 mrg * Separate logically distinct chunks with a single newline. This 138 1.1 mrg obviously applies between functions, but also applies within a 139 1.1 mrg function or block or structure definition. 140 1.1 mrg 141 1.1 mrg * Use a newline after a block of variable declarations. 142 1.1 mrg 143 1.1 mrg * Use a single space before a left parenthesis, except where the 144 1.1 mrg standard will not allow it, (eg. when defining a parameterized macro). 145 1.1 mrg 146 1.1 mrg * Don't eliminate newlines just because things would still fit on one 147 1.1 mrg line. This breaks the expected visual structure of the code making 148 1.1 mrg it much harder to read and understand: 149 1.1 mrg 150 1.1 mrg if (condition) foo (); else bar (); /* Yuck! */ 151 1.1 mrg 152 1.1 mrg 153 1.1 mrg Function Definitions 154 1.1 mrg ==================== 155 1.1 mrg 156 1.1 mrg Function definitions should take the following form: 157 1.1 mrg 158 1.1 mrg void 159 1.1 mrg my_function (int argument) 160 1.1 mrg { 161 1.1 mrg do_my_things (); 162 1.1 mrg } 163 1.1 mrg 164 1.1 mrg If all the parameters to a function fit naturally on one line, format 165 1.1 mrg them that way. Otherwise, put one argument on each line, adding 166 1.1 mrg whitespace so that the parameter names are aligned with each other. 167 1.1 mrg 168 1.1 mrg I.e., do either this: 169 1.1 mrg 170 1.1 mrg void 171 1.1 mrg short_arguments (const char *str, int x, int y, int z) 172 1.1 mrg { 173 1.1 mrg } 174 1.1 mrg 175 1.1 mrg or this: 176 1.1 mrg 177 1.1 mrg void 178 1.1 mrg long_arguments (const char *char_star_arg, 179 1.1 mrg int int_arg, 180 1.1 mrg double *double_star_arg, 181 1.1 mrg double double_arg) 182 1.1 mrg { 183 1.1 mrg } 184 1.1 mrg 185 1.1 mrg 186 1.1 mrg Mode lines 187 1.1 mrg ========== 188 1.1 mrg 189 1.1 mrg Given the rules above, what is the best way to simplify one's life as 190 1.1 mrg a code monkey? Get your editor to do most of the tedious work of 191 1.1 mrg beautifying your code! 192 1.1 mrg 193 1.1 mrg As a reward for reading this far, here are some mode lines for the more 194 1.1 mrg popular editors: 195 1.1 mrg /* 196 1.1 mrg * vim:sw=4:sts=4:ts=8:tw=78:fo=tcroq:cindent:cino=\:0,(0 197 1.1 mrg * vim:isk=a-z,A-Z,48-57,_,.,-,> 198 1.1 mrg */ 199 1.1 mrg 200