~pixelherodev/zyg

ref: 7dccbd7d9dc502f2cd859c4c7ebd84a0d8f3acd7 zyg/style -rw-r--r-- 2.6 KiB
7dccbd7dNoam Preil merge 3 months ago
                                                                                
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
          • Avoid macros where other alternatives exist

          • Only use forward-gotos, and only where it is readable

          • Tabs, not spaces.

          •  surround a binary operator (particular a low precedence
             one) with spaces; don't try to write the most compact
             code possible but rather the most readable.

          •  parenthesize expressions involving arithmetic and bit-
             wise operators; otherwise don't parenthesize heavily

          •  no white space before opening braces.

          •  no white space after the keywords `if', `for', `while',
             etc.

          •  no braces around single-line blocks (e.g., `if', `for',
             and `while' bodies).

          •  integer-valued functions return -1 on error, 0 or posi-
             tive on success.

          •  enum or #defined constants should be UPPERCASE.

          •  automatic variables (local variables inside a function)
             are never initialized at declaration.

          •  follow the standard idioms: use `x < 0' not `0 > x', etc.

          •  don't write `!strcmp' (nor `!memcmp', etc.)  nor
             `if(memcmp(a, b, c))'; always explicitly compare the
             result of string or memory comparison with zero using a
             relational operator.

          •  One statement should have one effect. Never use e.g. `x[a++] = b`;
             use `x[a] = b; a += 1;` instead.

          •  Don't use prefix or postfix operators (a++ or --a, for instance),
             use the assignment forms instead (e.g. `a += 1`).

          Ultimately, the goal is to write code that fits in with the
          other code around it and the system as a whole.  If the file
          you are editing already deviates from these guidelines, do
          what it does.  After you edit a file, a reader should not be
          able to tell just from coding style which parts you worked
          on.

        COMMENTS
          If your code is readable, you shouldn't need many comments.
          A line or two comment above a function explaining what it
          does is always welcome.

          Comment any code you find yourself wondering about for more
          than 2 seconds, even if it's to say that you don't under-
          stand what's going on.  Explain why.

          Don't use commenting as an excuse for writing confusing
          code.  Rewrite the code to make it clear.

        EFFICIENCY
          Do the simple thing.  Don't optimize unless you've measured
          the code and it is too slow.  Fix the data structures and
          the algorithms instead of going for little 5% tunings.