moparisthebest/pacman
1
0
Fork 0
mirror of https://github.com/moparisthebest/pacman synced 2025-02-28 09:21:53 -05:00
Code Issues Releases Wiki Activity

Turn HACKING into an asciidoc document

Browse Source 
Add some hints so we can use asciidoc on the HACKING document. It is still
readable as text, but a simple 'asciidoc HACKING' command will give you a
nice pretty guide now.

Signed-off-by: Dan McGee <dan@archlinux.org>
This commit is contained in:
Dan McGee 2007-11-20 18:58:09 -06:00
parent 4696ad6cad
commit 5f28996220
1 changed files with 55 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
HACKING
View File

@ -1,29 +1,34 @@
Contributing to pacman
======================
In addition to this file, please read 'submitting-patches' and
'translation-help' in the same directory for additional info on contributing.
In addition to this file, please read `submitting-patches` and
`translation-help` in the same directory for additional info on contributing.
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:
/* vim: set ts=2 sw=2 noet: */
+
[C]
code~~~~~~~~~~
/* vim: set ts=2 sw=2 noet: */
code~~~~~~~~~~
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/closing
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.
for(lp = list; lp; lp = lp->next) {
+
[C]
code~~~~~~~~~~
for(lp = list; lp; lp = lp->next) {
newlist = _alpm_list_add(newlist, strdup(lp->data));
}
}
while(it) {
while(it) {
ptr = it->next;
if(fn) {
fn(it->data);
@ -32,23 +37,29 @@ Coding style
}
free(it);
it = ptr;
}
}
code~~~~~~~~~~
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.
alpm_list_t *alpm_list_add(alpm_list_t *list, void *data)
{
+
[C]
code~~~~~~~~~~
alpm_list_t *alpm_list_add(alpm_list_t *list, void *data)
{
alpm_list_t *ptr, *lp;
ptr = list;
if(ptr == NULL) {
...
}
...
}
code~~~~~~~~~~
4. Comments should be ANSI-C89 compliant. That means no "// Comment" style;
use only "/* Comment */" style.
4. Comments should be ANSI-C89 compliant. That means no `// Comment` style;
use only `/* Comment */` style.
/* This is a comment */
NOT
@ -81,31 +92,45 @@ Coding style
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:
[C]
code~~~~~~~~~~
#include "config.h"
#include <standardheader.h>
#include <another.h>
#include <...>
code~~~~~~~~~~
Follow this with some more headers, depending on whether the file is in libalpm
or pacman proper. For libalpm:
[C]
code~~~~~~~~~~
/* libalpm */
#include "yourfile.h"
#include "alpm_list.h"
#include "anythingelse.h"
code~~~~~~~~~~
For pacman:
[C]
code~~~~~~~~~~
#include <alpm.h>
#include <alpm_list.h>
/* pacman */
#include "yourfile.h"
#include "anythingelse.h"
code~~~~~~~~~~
vim: set ts=2 sw=2 et:
/////
vim: set ts=2 sw=2 syntax=asciidoc et:
/////