summaryrefslogtreecommitdiff
path: root/HACKING
diff options
context:
space:
mode:
authorDan McGee <dan@archlinux.org>2010-07-02 18:29:37 -0500
committerDan McGee <dan@archlinux.org>2010-07-02 18:29:37 -0500
commit686b8c146398c5ba9feee2c1fa10bf9e598b2ce8 (patch)
tree0353500bc444ac60cef120ea6d722c94badfe8ca /HACKING
parent1a9db4cac7cf308188298db48dde5d80ce86a7e9 (diff)
parentfcb4f0264f2b8e0a6ed1e7eebfe00f662ba94ef2 (diff)
downloadpacman-686b8c146398c5ba9feee2c1fa10bf9e598b2ce8.tar.xz
Merge branch 'maint'
Conflicts: scripts/makepkg.sh.in
Diffstat (limited to 'HACKING')
-rw-r--r--HACKING36
1 files changed, 18 insertions, 18 deletions
diff --git a/HACKING b/HACKING
index 537d9a37..c659ff0b 100644
--- a/HACKING
+++ b/HACKING
@@ -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
~~~~~~~~~~~~~~~~~~~~~~