
Many of these are pointless (e.g. there is no need to explicitly turn on spellchecking and language dictionaries for the manpages by default). The only useful modelines are the ones enforcing the project coding standards for indentation style (and "maybe" filetype/syntax, but everything except the asciidoc manpages and makepkg.conf is already autodetected), and indent style can be applied more easily with .editorconfig Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
196 lines
4.8 KiB
Text
196 lines
4.8 KiB
Text
Pacman - Contributing
|
|
=====================
|
|
|
|
This file is meant to give you a brief overview of coding style and other
|
|
concerns when hacking on pacman. If you are interested in contributing, please
|
|
read link:submitting-patches.html[submitting-patches] and
|
|
link:translation-help.html[translation-help] as well.
|
|
|
|
Coding Style
|
|
------------
|
|
|
|
1. All code should be indented with tabs. (Ignore the use of only spaces in
|
|
this file.) A tab size of two spaces is used when calculating line widths,
|
|
which should be a maximum of 80 characters. By default, source files
|
|
contain the following Vim modeline:
|
|
+
|
|
[source,C]
|
|
-------------------------------------------
|
|
/* vim: set noet: */
|
|
-------------------------------------------
|
|
|
|
2. When opening new blocks such as 'while', 'if', or 'for', leave the opening
|
|
brace on the same line as the beginning of the codeblock. The closing brace
|
|
gets its own line (the only exception being 'else'). Do not use extra
|
|
spaces around the parentheses of the block. ALWAYS use opening and closing
|
|
braces, even if it's just a one-line block. This reduces future error when
|
|
blocks are expanded beyond one line.
|
|
+
|
|
[source,C]
|
|
-------------------------------------------
|
|
for(lp = list; lp; lp = lp->next) {
|
|
newlist = _alpm_list_add(newlist, strdup(lp->data));
|
|
}
|
|
|
|
while(it) {
|
|
ptr = it->next;
|
|
if(fn) {
|
|
fn(it->data);
|
|
} else {
|
|
return 1;
|
|
}
|
|
free(it);
|
|
it = ptr;
|
|
}
|
|
-------------------------------------------
|
|
|
|
3. When declaring a new function, put the opening and closing braces on their
|
|
own line. Also, when declaring a pointer, do not put a space between the
|
|
asterisk and the variable name.
|
|
+
|
|
[source,C]
|
|
-------------------------------------------
|
|
alpm_list_t *alpm_list_add(alpm_list_t *list, void *data)
|
|
{
|
|
alpm_list_t *ptr, *lp;
|
|
|
|
ptr = list;
|
|
if(ptr == NULL) {
|
|
...
|
|
}
|
|
...
|
|
}
|
|
-------------------------------------------
|
|
|
|
4. Comments should be ANSI-C89 compliant. That means no `// Comment` style;
|
|
use only `/* Comment */` style.
|
|
|
|
/* This is a comment */
|
|
NOT
|
|
// This is a comment
|
|
|
|
5. Return statements should *not* be written like function calls.
|
|
|
|
return 0;
|
|
NOT
|
|
return(0);
|
|
|
|
6. When using strcmp() (or any function that returns 0 on success) in a
|
|
conditional statement, use != 0 or == 0 and not the negation (!) operator.
|
|
It reads much cleaner for humans (using a negative to check for success is
|
|
confusing) and the compiler will treat it correctly anyway.
|
|
|
|
if(strcmp(a, b) == 0)
|
|
NOT
|
|
if(!strcmp(a, b))
|
|
|
|
7. Use spaces around almost all arithmetic, comparison and assignment
|
|
operators and after all ',;:' separators.
|
|
|
|
foobar[2 * size + 1] = function(a, 6);
|
|
NOT
|
|
foobar[2*size+1]=function(a,6);
|
|
|
|
for(a = 0; a < n && n > 0; a++, n--) {}
|
|
NOT
|
|
for(a=0;a<n&&n>0;a++,n--) {}
|
|
|
|
8. Declare all variables at the start of the block.
|
|
[source,C]
|
|
-------------------------------------------
|
|
int SYMEXPORT alpm_db_remove_server(alpm_db_t *db, const char *url)
|
|
{
|
|
char *newurl, *vdata = NULL;
|
|
|
|
newurl = url;
|
|
if(!newurl) {
|
|
return -1;
|
|
}
|
|
|
|
...
|
|
|
|
if(vdata) {
|
|
...
|
|
}
|
|
|
|
return 1;
|
|
}
|
|
-------------------------------------------
|
|
|
|
NOT
|
|
|
|
[source,C]
|
|
-------------------------------------------
|
|
int SYMEXPORT alpm_db_remove_server(alpm_db_t *db, const char *url)
|
|
{
|
|
char *newurl = url;
|
|
|
|
if(!newurl) {
|
|
return -1;
|
|
}
|
|
|
|
char *vdata = NULL;
|
|
|
|
if(vdata) {
|
|
...
|
|
}
|
|
|
|
return 1;
|
|
}
|
|
-------------------------------------------
|
|
|
|
|
|
Other Concerns
|
|
--------------
|
|
|
|
Header Includes
|
|
~~~~~~~~~~~~~~~
|
|
|
|
Currently our #include usage is in messy shape, but this is no reason to
|
|
continue down this messy path. When adding an include to a file, follow this
|
|
general pattern, including blank lines:
|
|
|
|
[source,C]
|
|
-------------------------------------------
|
|
#include <standardheader.h>
|
|
#include <another.h>
|
|
#include <...>
|
|
-------------------------------------------
|
|
|
|
Follow this with some more headers, depending on whether the file is in libalpm
|
|
or pacman proper. For libalpm:
|
|
|
|
[source,C]
|
|
-------------------------------------------
|
|
/* libalpm */
|
|
#include "yourfile.h"
|
|
#include "alpm_list.h"
|
|
#include "anythingelse.h"
|
|
-------------------------------------------
|
|
|
|
For pacman:
|
|
|
|
[source,C]
|
|
-------------------------------------------
|
|
#include <alpm.h>
|
|
#include <alpm_list.h>
|
|
|
|
/* pacman */
|
|
#include "yourfile.h"
|
|
#include "anythingelse.h"
|
|
-------------------------------------------
|
|
|
|
Never directly include config.h. This will always be added via Makefiles.
|
|
|
|
GDB and Valgrind Usage
|
|
~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
When using GDB or valgrind on pacman, you will want to run it on the actual
|
|
binary rather than the shell script wrapper produced by libtool. The actual
|
|
binary lives at `src/pacman/.libs/lt-pacman`, and will exist after running
|
|
`./src/pacman/pacman` at least once.
|
|
|
|
For example, to run valgrind:
|
|
|
|
./src/pacman/pacman
|
|
valgrind --leak-check=full -- src/pacman/.libs/lt-pacman -Syu
|