documentation:coding_practices
Releases
Current version
Git/Latestdiff: 1.5.6
Latest Snapshots
Produced after each commit or rebase to new upstream version
GIT
RSBAC source code, can be unstable sometimes
Events
No events planned
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
documentation:coding_practices [2005/11/22 12:50] kang spelling |
documentation:coding_practices [2006/05/02 15:40] (current) |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| General kernel rules are, no more than 10 variables per function, no more than 2 or 3 console screens of text per function (except switch..case), no more than 3 levels of indentation. | General kernel rules are, no more than 10 variables per function, no more than 2 or 3 console screens of text per function (except switch..case), no more than 3 levels of indentation. | ||
| - | Of course this may not always be applicable, but when you reach any of thoses values you can start checking if there is not something you could have made simpler :) | + | Of course this may not always be applicable, but when you reach any of those values you can start checking if there is not something you could have made simpler :) |
| ===== Indent ===== | ===== Indent ===== | ||
| Line 47: | Line 47: | ||
| If your code is full of endif}}}}}}} then it should be rewritten :) | 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. | 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 thoses too much. | + | Please dont use them too much. |
| * Do not comment without reason. Why commenting when there is NO need to ? | * Do not comment without reason. Why commenting when there is NO need to ? | ||
| Line 136: | Line 136: | ||
| 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: | 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: | ||
| - | * Reduce the code size, the number of lines to read, ... | + | * 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) | * 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. | * People who didn't write the code do not know where the code has been duplicated. They will probably miss it. | ||
| - | * It enhance your coding speed ! Less typing, less checking ! | + | * It enhance syour coding speed ! Less typing, less checking ! |
documentation/coding_practices.1132660236.txt.gz · Last modified: 2006/05/02 15:40 (external edit)