“linux/rsbac” and “linux/include/rsbac” have been re-indented with “indent -kr -i8”, which after several tests seemed to be the best compromise. However, due to the previous space-based indentation which was different in some parts of the source code, and only 2 spaces, many functions or code alignement (especially when there is 10 levels of indentation, *cough*) have been visually messed up.

While I fixed most, over so many lines of code its impossible to do in a few days. If you find something wrong, and there are probably many places where it is, please, please fix it. It takes only a few mins when you see it vs hours and hours when doing all files, as this can't be automated properly.

• No reason to tell what file we are in, its written on the editor, and we know when we're at the last line !

Wrong

File lala.c
....
...
/* end of file lala.c */

• No inline comments, its hard to read when you read millions of lines a day

Wrong

...
if(!lala) { /* check if lala is right */

Right

...
/* check if lala is right */
if(!lala) {
...

* No reason to make end of functions/if/etc in most cases Wrong

#ifdef CONFIG_BLAH
...
...
#endif /* end CONFIG_BLAH */

If your code is full of endif}}}}}}} then it should be rewritten :) Ok, sarcasms apart, in most case its easy to see or to push “%” (or equivalent in non-vim editors) to see where the ifdef is from. For functions, your editor should tell you in which function you are and in which sub-bracket you are. Please dont use them too much.

• Do not comment without reason. Why commenting when there is NO need to ?

Wrong

/* MAC */
#ifdef CONFIG_RSBAC_MAC
(three lines of code)
#endif /* end MAC */

• Never describe what your line of code does. We can read. Tell what the function is for, instead, and only comment tricky hacks.

Wrong

/* No perm? Failure */
return -EPERM;

• Try to make nice code blocks :)

Right

/*  Blablablabla
 *  lalalalal
 *  llulu
 */

This is much more readable and scales on any tab size, doesn't needs spaces, than: Wrong

/* blab */
/* lalalalaal */
/* llulslu */

• Do not use separators with comments, if you have to use it then your code is really too complex. (Actually I've only seen some to separate functions. Well! Functions are already separated.) The only time it looks ok is for example, when explaining the separation and that it really indicates something.

Wrong

blala() {
...
}

/*********/

lili() {
...
}

Acceptable

blala() {
...
}

/* lili_* are functions visible from userspace */

lili_hm() {
...
}

lili_ah() {

• We know what declarations are (especially when empty..:)

Wrong

/******************************************/
/*   DECLARATIONS                         */
/******************************************/

/******************************************/
/*   CODE                                 */
/******************************************/

Right

int lala=0;
rsbac_lala *la;
..

myfunct..

Refactoring is the process of taking repetitive code out of the current function and to make a new one. All code should not be refactorized, however, so don't over-factorize, but it is usually a good thing:

• Reduces the code size, the number of lines to read, …
• Make things easy: changes are only in one place instead of 10 (and forgetting the 11th)
• People who didn't write the code do not know where the code has been duplicated. They will probably miss it.
• It enhance syour coding speed ! Less typing, less checking !

The kernel syntax is k&r style.

/* No indent before ifdefs */
if(xxx) {
#ifdef CONFIG_RSBAC
    rsbac_hello_func();
#endif

/* Tabs are made for indenting, spaces are for
 * formatting comments if ever                 needed :)
 */ 

/* Iteration */
if() {
...
}
while() {
...
}

/* Function */
rsbac_moin ()
{
...
}

If this document is not 100% correct or complete feel free to modify it!