]>
Commit | Line | Data |
---|---|---|
60918275 LP |
1 | |
2 | - 8ch indent, no tabs | |
3 | ||
c170f3a4 LP |
4 | - Variables and functions *must* be static, unless they have a |
5 | protoype, and are supposed to be exported. | |
60918275 | 6 | |
c170f3a4 LP |
7 | - structs in MixedCase, variables + functions in lower_case |
8 | ||
9 | - The destructors always unregister the object from the next bigger | |
60918275 LP |
10 | object, not the other way around |
11 | ||
c170f3a4 | 12 | - To minimize strict aliasing violations we prefer unions over casting |
60918275 | 13 | |
c170f3a4 | 14 | - For robustness reasons destructors should be able to destruct |
60918275 LP |
15 | half-initialized objects, too |
16 | ||
c170f3a4 | 17 | - Error codes are returned as negative Exxx. i.e. return -EINVAL. There |
60918275 | 18 | are some exceptions: for constructors its is OK to return NULL on |
c170f3a4 LP |
19 | OOM. For lookup functions NULL is fine too for "not found". |
20 | ||
21 | Be strict with this. When you write a function that can fail due to | |
22 | more than one cause, it *really* should have "int" as return value | |
23 | for the error code. | |
24 | ||
25 | - Don't bother with error checking if writing to stdout/stderr worked. | |
26 | ||
27 | - Do not log errors from "library" code, only do so from "main | |
28 | program" code. | |
29 | ||
30 | - Always check OOM. There's no excuse. In program code you can use | |
31 | "log_oom()" for then printing a short message. | |
debf93a4 LP |
32 | |
33 | - Do not issue NSS requests (that includes user name and host name | |
34 | lookups) from the main daemon as this might trigger deadlocks when | |
01233fc7 | 35 | those lookups involve synchronously talking to services that we |
f49f49ba | 36 | would need to start up |
debf93a4 | 37 | |
debf93a4 | 38 | - Don't synchronously talk to any other service, due to risk of |
f49f49ba | 39 | deadlocks |
c170f3a4 LP |
40 | |
41 | - Avoid fixed sized string buffers, unless you really know the maximum | |
42 | size and that maximum size is small. They are a source of errors, | |
43 | since they result in strings to be truncated. Often it is nicer to | |
44 | use dynamic memory, or alloca(). If you do allocate fixed size | |
45 | strings on the stack, then it's probably only OK if you either use a | |
46 | maximum size such as LINE_MAX, or count in detail the maximum size a | |
47 | string can have. Or in other words, if you use "char buf[256]" then | |
48 | you are likely doing something wrong! | |
49 | ||
50 | - Stay uniform. For example, always use "usec_t" for time | |
51 | values. Don't usec mix msec, and usec and whatnot. | |
52 | ||
53 | - Make use of _cleanup_free_ and friends. It makes your code much | |
54 | nicer to read! | |
55 | ||
56 | - Be exceptionally careful when formatting and parsing floating point | |
57 | numbers. Their syntax is locale dependent (i.e. "5.000" in en_US is | |
58 | generally understood as 5, while on de_DE as 5000.). | |
59 | ||
60 | - Try to use this: | |
61 | ||
62 | void foo() { | |
63 | } | |
64 | ||
65 | instead of this: | |
66 | ||
67 | void foo() | |
68 | { | |
69 | } | |
70 | ||
71 | But it's OK if you don't. | |
72 | ||
73 | - Don't write "foo ()", write "foo()". | |
74 | ||
75 | - Please use streq() and strneq() instead of strcmp(), strncmp() where applicable. | |
76 | ||
77 | - Please do not allocate variables on the stack in the middle of code, | |
78 | even if C99 allows it. Wrong: | |
79 | ||
80 | { | |
81 | a = 5; | |
82 | int b; | |
83 | b = a; | |
84 | } | |
85 | ||
86 | Right: | |
87 | ||
88 | { | |
89 | int b; | |
90 | a = 5; | |
91 | b = a; | |
92 | } | |
93 | ||
94 | - Unless you allocate an array, "double" is always the better choice | |
95 | than "float". Processors speak "double" natively anyway, so this is | |
96 | no speed benefit, and on calls like printf() "float"s get upgraded | |
97 | to "double"s anyway, so there is no point. | |
98 | ||
99 | - Don't invoke functions when you allocate variables on the stack. Wrong: | |
100 | ||
101 | { | |
102 | int a = foobar(); | |
103 | uint64_t x = 7; | |
104 | } | |
105 | ||
106 | Right: | |
107 | ||
108 | { | |
109 | int a; | |
110 | uint64_t x = 7; | |
111 | ||
112 | a = foobar(); | |
113 | } | |
114 | ||
115 | - Use "goto" for cleaning up, and only use it for that. i.e. you may | |
116 | only jump to the end of a function, and little else. | |
117 | ||
118 | - Think about the types you use. If a value cannot sensibly be | |
119 | negative don't use "int", but use "unsigned". | |
120 | ||
121 | - Don't use types like "short". They *never* make sense. Use ints, | |
122 | longs, long longs, all in unsigned+signed fashion, and the fixed | |
123 | size types uint32_t and so on, but nothing else. |