(Difference between revisions)
|
|
| Line 31: |
Line 31: |
| | XXXX | | XXXX |
| | } | | } |
| - | | + | * Naming |
| - | | + | ** xxxx_yyyy_zzzz |
| - | | + | ** xxxxYyyyZzzz |
| - | * Naming, naming … | + | |
| - | ** xxxx_yyyy_zzzz VS xxxxYyyyZzzz | + | |
| | ** Choose one and keep it, but not mix | | ** Choose one and keep it, but not mix |
| - | | + | ** CamelCase is discouraged. The exception is if the code is heavily tied to some library which uses such notation |
| | * Pre-release test | | * Pre-release test |
| | ** Memory Usage Check Tool: Valgrind | | ** Memory Usage Check Tool: Valgrind |
| | ** Static Code Check Tool: K7 | | ** Static Code Check Tool: K7 |
| | ** Checkpatch.pl | | ** Checkpatch.pl |
Revision as of 09:01, 3 August 2010
Code style common rule
- The most important thing about coding style is to keep your source consistent.
- Add head comments. Follow information is needed:
- License
- Brief description
- Author
- Version (Optional)
- Tab/blank space indention: Using once method and keep consistent for the component
- 4 spaces
- Add “set expandtab tabstop=4 shiftwidth=4” to your .vimrc
- Use “:%retab” in cmd mode to replace all existing Tabs
- one tab
- Write comments appropriately
- Comments for functional block but not for code line
- Comment lines before the described code block
- One blank line before comment lines to separate it from other logics
- Maximum text width is 80 columns in a line, with very few exceptions
- Deal with “()” and “{}” correctly
- Add 1 blank space when with reserved word: for (), if ()
- Directly connect when with function: functionA()
- Two {} Styles, choose one and keep it, but not mix:
Style 1:
If (XXXXX) {
XXXX
}
Style 2:
If (XXXXX)
{
XXXX
}
- Naming
- xxxx_yyyy_zzzz
- xxxxYyyyZzzz
- Choose one and keep it, but not mix
- CamelCase is discouraged. The exception is if the code is heavily tied to some library which uses such notation
- Pre-release test
- Memory Usage Check Tool: Valgrind
- Static Code Check Tool: K7
- Checkpatch.pl