mirror of
https://github.com/moparisthebest/pacman
synced 2024-11-10 03:25:01 -05:00
0303b26b1e
This was discussed and more or less agreed upon on the mailing list. A huge checkin, but if we just do it and let people adjust the pain will end soon enough. Rebasing should be relatively straighforward for anyone that sees conflicts; just be sure you use the new return style if possible. The following semantic patch was used to do the change, along with some hand-massaging in order to preserve parenthesis where appropriate: The semantic match that finds this problem is as follows, although some hand-massaging was done in order to keep parenthesis where appropriate: (http://coccinelle.lip6.fr/) // <smpl> @@ expression a; @@ - return(a); + return a; // </smpl> A macros_file was also provided with the following content: Additional steps taken, mainly for ASSERT() macros: $ sed -i -e 's#return(NULL)#return NULL#' lib/libalpm/*.c $ sed -i -e 's#return(-1)#return -1#' lib/libalpm/*.c Signed-off-by: Dan McGee <dan@archlinux.org>
152 lines
4.0 KiB
Plaintext
152 lines
4.0 KiB
Plaintext
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) By default, source files contain the following VIM modeline:
|
|
+
|
|
[source,C]
|
|
-------------------------------------------
|
|
/* vim: set ts=2 sw=2 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. The sizeof() operator should accept a type, not a value. (TODO: in certain
|
|
cases, it may be better- should this be a set guideline? Read "The Practice
|
|
of Programming")
|
|
|
|
sizeof(alpm_list_t);
|
|
NOT
|
|
sizeof(*mylist);
|
|
|
|
7. 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))
|
|
|
|
|
|
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 "config.h"
|
|
|
|
#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"
|
|
-------------------------------------------
|
|
|
|
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
|
|
|
|
/////
|
|
vim: set ts=2 sw=2 syntax=asciidoc et:
|
|
/////
|