diff options
author | Dan McGee <dan@archlinux.org> | 2010-07-02 18:29:37 -0500 |
---|---|---|
committer | Dan McGee <dan@archlinux.org> | 2010-07-02 18:29:37 -0500 |
commit | 686b8c146398c5ba9feee2c1fa10bf9e598b2ce8 (patch) | |
tree | 0353500bc444ac60cef120ea6d722c94badfe8ca /HACKING | |
parent | 1a9db4cac7cf308188298db48dde5d80ce86a7e9 (diff) | |
parent | fcb4f0264f2b8e0a6ed1e7eebfe00f662ba94ef2 (diff) |
Merge branch 'maint'
Conflicts:
scripts/makepkg.sh.in
Diffstat (limited to 'HACKING')
-rw-r--r-- | HACKING | 36 |
1 files changed, 18 insertions, 18 deletions
@@ -12,10 +12,10 @@ 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: + -[code,C] -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[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 @@ -24,8 +24,8 @@ Coding style braces, even if it's just a one-line block. This reduces future error when blocks are expanded beyond one line. + -[code,C] -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[source,C] +------------------------------------------- for(lp = list; lp; lp = lp->next) { newlist = _alpm_list_add(newlist, strdup(lp->data)); } @@ -40,14 +40,14 @@ while(it) { 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. + -[code,C] -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[source,C] +------------------------------------------- alpm_list_t *alpm_list_add(alpm_list_t *list, void *data) { alpm_list_t *ptr, *lp; @@ -58,7 +58,7 @@ alpm_list_t *alpm_list_add(alpm_list_t *list, void *data) } ... } -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +------------------------------------------- 4. Comments should be ANSI-C89 compliant. That means no `// Comment` style; use only `/* Comment */` style. @@ -101,37 +101,37 @@ 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: -[code,C] -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[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: -[code,C] -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[source,C] +------------------------------------------- /* libalpm */ #include "yourfile.h" #include "alpm_list.h" #include "anythingelse.h" -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +------------------------------------------- For pacman: -[code,C] -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[source,C] +------------------------------------------- #include <alpm.h> #include <alpm_list.h> /* pacman */ #include "yourfile.h" #include "anythingelse.h" -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +------------------------------------------- GDB and Valgrind Usage ~~~~~~~~~~~~~~~~~~~~~~ |