4 This file is meant to give you a brief overview of coding style and other
5 concerns when hacking on pacman. If you are interested in contributing, please
6 read link:submitting-patches.html[submitting-patches] and
7 link:translation-help.html[translation-help] as well.
12 1. All code should be indented with tabs. (Ignore the use of only spaces in
13 this file) By default, source files contain the following VIM modeline:
16 -------------------------------------------
17 /* vim: set ts=2 sw=2 noet: */
18 -------------------------------------------
20 2. When opening new blocks such as 'while', 'if', or 'for', leave the opening
21 brace on the same line as the beginning of the codeblock. The closing brace
22 gets its own line (the only exception being 'else'). Do not use extra
23 spaces around the parentheses of the block. ALWAYS use opening and closing
24 braces, even if it's just a one-line block. This reduces future error when
25 blocks are expanded beyond one line.
28 -------------------------------------------
29 for(lp = list; lp; lp = lp->next) {
30 newlist = _alpm_list_add(newlist, strdup(lp->data));
43 -------------------------------------------
45 3. When declaring a new function, put the opening and closing braces on their
46 own line. Also, when declaring a pointer, do not put a space between the
47 asterisk and the variable name.
50 -------------------------------------------
51 alpm_list_t *alpm_list_add(alpm_list_t *list, void *data)
53 alpm_list_t *ptr, *lp;
61 -------------------------------------------
63 4. Comments should be ANSI-C89 compliant. That means no `// Comment` style;
64 use only `/* Comment */` style.
66 /* This is a comment */
70 5. Return statements should *not* be written like function calls.
76 6. The sizeof() operator should accept a type, not a value. (TODO: in certain
77 cases, it may be better- should this be a set guideline? Read "The Practice
84 7. When using strcmp() (or any function that returns 0 on success) in a
85 conditional statement, use != 0 or == 0 and not the negation (!) operator.
86 It reads much cleaner for humans (using a negative to check for success is
87 confusing) and the compiler will treat it correctly anyway.
93 8. Use spaces around almost all arithmetic, comparison and assignment
94 operators and after all ',;:' separators.
96 foobar[2 * size + 1] = function(a, 6);
98 foobar[2*size+1]=function(a,6);
100 for(a = 0; a < n && n > 0; a++,n--) {}
102 for(a=0;a<n&&n>0;a++,n--) {}
111 Currently our #include usage is in messy shape, but this is no reason to
112 continue down this messy path. When adding an include to a file, follow this
113 general pattern, including blank lines:
116 -------------------------------------------
117 #include <standardheader.h>
120 -------------------------------------------
122 Follow this with some more headers, depending on whether the file is in libalpm
123 or pacman proper. For libalpm:
126 -------------------------------------------
128 #include "yourfile.h"
129 #include "alpm_list.h"
130 #include "anythingelse.h"
131 -------------------------------------------
136 -------------------------------------------
138 #include <alpm_list.h>
141 #include "yourfile.h"
142 #include "anythingelse.h"
143 -------------------------------------------
145 Never directly include config.h. This will always be added via Makefiles.
147 GDB and Valgrind Usage
148 ~~~~~~~~~~~~~~~~~~~~~~
150 When using GDB or valgrind on pacman, you will want to run it on the actual
151 binary rather than the shell script wrapper produced by libtool. The actual
152 binary lives at `src/pacman/.libs/lt-pacman`, and will exist after running
153 `./src/pacman/pacman` at least once.
155 For example, to run valgrind:
158 valgrind --leak-check=full -- src/pacman/.libs/lt-pacman -Syu
161 vim:set ts=4 sw=4 syntax=asciidoc noet spell spelllang=en_us: