comparison mupdf-source/thirdparty/curl/docs/CODE_STYLE.md @ 2:b50eed0cc0ef upstream

ADD: MuPDF v1.26.7: the MuPDF source as downloaded by a default build of PyMuPDF 1.26.4. The directory name has changed: no version number in the expanded directory now.
author Franz Glasner <fzglas.hg@dom66.de>
date Mon, 15 Sep 2025 11:43:07 +0200
parents
children
comparison
equal deleted inserted replaced
1:1d09e1dec1d9 2:b50eed0cc0ef
1 # curl C code style
2
3 Source code that has a common style is easier to read than code that uses
4 different styles in different places. It helps making the code feel like one
5 single code base. Easy-to-read is a very important property of code and helps
6 making it easier to review when new things are added and it helps debugging
7 code when developers are trying to figure out why things go wrong. A unified
8 style is more important than individual contributors having their own personal
9 tastes satisfied.
10
11 Our C code has a few style rules. Most of them are verified and upheld by the
12 `lib/checksrc.pl` script. Invoked with `make checksrc` or even by default by
13 the build system when built after `./configure --enable-debug` has been used.
14
15 It is normally not a problem for anyone to follow the guidelines, as you just
16 need to copy the style already used in the source code and there are no
17 particularly unusual rules in our set of rules.
18
19 We also work hard on writing code that are warning-free on all the major
20 platforms and in general on as many platforms as possible. Code that obviously
21 will cause warnings will not be accepted as-is.
22
23 ## Naming
24
25 Try using a non-confusing naming scheme for your new functions and variable
26 names. It doesn't necessarily have to mean that you should use the same as in
27 other places of the code, just that the names should be logical,
28 understandable and be named according to what they're used for. File-local
29 functions should be made static. We like lower case names.
30
31 See the [INTERNALS](INTERNALS.md) document on how we name non-exported
32 library-global symbols.
33
34 ## Indenting
35
36 We use only spaces for indentation, never TABs. We use two spaces for each new
37 open brace.
38
39 if(something_is_true) {
40 while(second_statement == fine) {
41 moo();
42 }
43 }
44
45 ## Comments
46
47 Since we write C89 code, **//** comments are not allowed. They weren't
48 introduced in the C standard until C99. We use only **/* comments */**.
49
50 /* this is a comment */
51
52 ## Long lines
53
54 Source code in curl may never be wider than 79 columns and there are two
55 reasons for maintaining this even in the modern era of very large and high
56 resolution screens:
57
58 1. Narrower columns are easier to read than very wide ones. There's a reason
59 newspapers have used columns for decades or centuries.
60
61 2. Narrower columns allow developers to easier show multiple pieces of code
62 next to each other in different windows. I often have two or three source
63 code windows next to each other on the same screen - as well as multiple
64 terminal and debugging windows.
65
66 ## Braces
67
68 In if/while/do/for expressions, we write the open brace on the same line as
69 the keyword and we then set the closing brace on the same indentation level as
70 the initial keyword. Like this:
71
72 if(age < 40) {
73 /* clearly a youngster */
74 }
75
76 You may omit the braces if they would contain only a one-line statement:
77
78 if(!x)
79 continue;
80
81 For functions the opening brace should be on a separate line:
82
83 int main(int argc, char **argv)
84 {
85 return 1;
86 }
87
88 ## 'else' on the following line
89
90 When adding an **else** clause to a conditional expression using braces, we
91 add it on a new line after the closing brace. Like this:
92
93 if(age < 40) {
94 /* clearly a youngster */
95 }
96 else {
97 /* probably grumpy */
98 }
99
100 ## No space before parentheses
101
102 When writing expressions using if/while/do/for, there shall be no space
103 between the keyword and the open parenthesis. Like this:
104
105 while(1) {
106 /* loop forever */
107 }
108
109 ## Use boolean conditions
110
111 Rather than test a conditional value such as a bool against TRUE or FALSE, a
112 pointer against NULL or != NULL and an int against zero or not zero in
113 if/while conditions we prefer:
114
115 result = do_something();
116 if(!result) {
117 /* something went wrong */
118 return result;
119 }
120
121 ## No assignments in conditions
122
123 To increase readability and reduce complexity of conditionals, we avoid
124 assigning variables within if/while conditions. We frown upon this style:
125
126 if((ptr = malloc(100)) == NULL)
127 return NULL;
128
129 and instead we encourage the above version to be spelled out more clearly:
130
131 ptr = malloc(100);
132 if(!ptr)
133 return NULL;
134
135 ## New block on a new line
136
137 We never write multiple statements on the same source line, even for very
138 short if() conditions.
139
140 if(a)
141 return TRUE;
142 else if(b)
143 return FALSE;
144
145 and NEVER:
146
147 if(a) return TRUE;
148 else if(b) return FALSE;
149
150 ## Space around operators
151
152 Please use spaces on both sides of operators in C expressions. Postfix **(),
153 [], ->, ., ++, --** and Unary **+, - !, ~, &** operators excluded they should
154 have no space.
155
156 Examples:
157
158 bla = func();
159 who = name[0];
160 age += 1;
161 true = !false;
162 size += -2 + 3 * (a + b);
163 ptr->member = a++;
164 struct.field = b--;
165 ptr = &address;
166 contents = *pointer;
167 complement = ~bits;
168 empty = (!*string) ? TRUE : FALSE;
169
170 ## No parentheses for return values
171
172 We use the 'return' statement without extra parentheses around the value:
173
174 int works(void)
175 {
176 return TRUE;
177 }
178
179 ## Parentheses for sizeof arguments
180
181 When using the sizeof operator in code, we prefer it to be written with
182 parentheses around its argument:
183
184 int size = sizeof(int);
185
186 ## Column alignment
187
188 Some statements cannot be completed on a single line because the line would be
189 too long, the statement too hard to read, or due to other style guidelines
190 above. In such a case the statement will span multiple lines.
191
192 If a continuation line is part of an expression or sub-expression then you
193 should align on the appropriate column so that it's easy to tell what part of
194 the statement it is. Operators should not start continuation lines. In other
195 cases follow the 2-space indent guideline. Here are some examples from
196 libcurl:
197
198 if(Curl_pipeline_wanted(handle->multi, CURLPIPE_HTTP1) &&
199 (handle->set.httpversion != CURL_HTTP_VERSION_1_0) &&
200 (handle->set.httpreq == HTTPREQ_GET ||
201 handle->set.httpreq == HTTPREQ_HEAD))
202 /* didn't ask for HTTP/1.0 and a GET or HEAD */
203 return TRUE;
204
205 If no parenthesis, use the default indent:
206
207 data->set.http_disable_hostname_check_before_authentication =
208 (0 != va_arg(param, long)) ? TRUE : FALSE;
209
210 Function invoke with an open parenthesis:
211
212 if(option) {
213 result = parse_login_details(option, strlen(option),
214 (userp ? &user : NULL),
215 (passwdp ? &passwd : NULL),
216 NULL);
217 }
218
219 Align with the "current open" parenthesis:
220
221 DEBUGF(infof(data, "Curl_pp_readresp_ %d bytes of trailing "
222 "server response left\n",
223 (int)clipamount));
224
225 ## Platform dependent code
226
227 Use **#ifdef HAVE_FEATURE** to do conditional code. We avoid checking for
228 particular operating systems or hardware in the #ifdef lines. The HAVE_FEATURE
229 shall be generated by the configure script for unix-like systems and they are
230 hard-coded in the `config-[system].h` files for the others.
231
232 We also encourage use of macros/functions that possibly are empty or defined
233 to constants when libcurl is built without that feature, to make the code
234 seamless. Like this example where the **magic()** function works differently
235 depending on a build-time conditional:
236
237 #ifdef HAVE_MAGIC
238 void magic(int a)
239 {
240 return a + 2;
241 }
242 #else
243 #define magic(x) 1
244 #endif
245
246 int content = magic(3);