Spruce up HACKING a bit
[pacman-ng.git] / HACKING
blob140b11c749b43ebc112251d7f3af1050aa447435
1 Contributing to pacman
2 ======================
4 In addition to this file, please read 'submitting-patches' and
5 'translation-help' in the same directory for additional info on contributing.
7 Coding style
8 ------------
10 1.  All code should be indented with tabs. (Ignore the use of only spaces in
11     this file) By default, source files contain the following VIM modeline:
13       /* vim: set ts=2 sw=2 noet: */
15 2.  When opening new blocks such as 'while', 'if', or 'for', leave the opening
16     brace on the same line as the beginning of the codeblock. The closing brace
17     gets its own line (the only exception being 'else'). Do not use extra
18     spaces around the parentheses of the block. ALWAYS use opening/closing
19     braces, even if it's just a one-line block. This reduces future error when
20     blocks are expanded beyond one line.
22     for(lp = list; lp; lp = lp->next) {
23       newlist = _alpm_list_add(newlist, strdup(lp->data));
24     }
26     while(it) {
27       ptr = it->next;
28       if(fn) {
29         fn(it->data);
30       } else {
31         return(1);
32       }
33       free(it);
34       it = ptr;
35     }
37 3.  When declaring a new function, put the opening and closing braces on their
38     own line. Also, when declaring a pointer, do not put a space between the
39     asterisk and the variable name.
41     alpm_list_t *alpm_list_add(alpm_list_t *list, void *data)
42     {
43       alpm_list_t *ptr, *lp;
45       ptr = list;
46      if(ptr == NULL) {
47      ...
48     }
50 4.  Comments should be ANSI-C89 compliant. That means no "// Comment" style;
51     use only "/* Comment */" style.
53     /* This is a comment */
54        NOT
55     // This is a comment
57 5.  Return statements should be written like a function call.
59     return(0);
60        NOT
61     return 0;
63 6.  The sizeof() operator should accept a type, not a value. (TODO: in certain
64     cases, it may be better- should this be a set guideline? Read "The Practice
65     of Programming")
67     sizeof(alpm_list_t);
68        NOT
69     sizeof(*mylist);
71 7.  When using strcmp() (or any function that returns 0 on success) in a
72     conditional statement, use != 0 or == 0 and not the negation (!) operator.
73     It reads much cleaner for humans (using a negative to check for success is
74     confusing) and the compiler will treat it correctly anyway.
76     if(strcmp(a, b) == 0)
77        NOT
78     if(!strcmp(a, b))
81 Other Concerns
82 --------------
84 Currently our #include usage is in messy shape, but this is no reason to
85 continue down this messy path. When adding an include to a file, follow this
86 general pattern, including blank lines:
88 #include "config.h"
90 #include <standardheader.h>
91 #include <another.h>
92 #include <...>
94 Follow this with some more headers, depending on whether the file is in libalpm
95 or pacman proper. For libalpm:
97 /* libalpm */
98 #include "yourfile.h"
99 #include "alpm_list.h"
100 #include "anythingelse.h"
102 For pacman:
104 #include <alpm.h>
105 #include <alpm_list.h>
107 /* pacman */
108 #include "yourfile.h"
109 #include "anythingelse.h"
111 vim: set ts=2 sw=2 et: