mirror of
https://github.com/moparisthebest/pacman
synced 2024-11-15 13:55:09 -05:00
4b3df10d5d
Signed-off-by: Pierre Neidhardt <ambrevar@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
201 lines
4.9 KiB
Plaintext
201 lines
4.9 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.) 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
|
|
|
|
/////
|
|
vim:set syntax=asciidoc noet spell spelllang=en_us:
|
|
/////
|