Meego Wiki
Views

Quality/TestSuite/MCTS/Code style common rule

From MeeGo wiki
< Quality | TestSuite | MCTS(Difference between revisions)
Jump to: navigation, search
 
(5 intermediate revisions not shown)
Line 1: Line 1:
-
Code style common rule
+
===Code style common rule===
* The most important thing about coding style is to keep your source consistent.
* The most important thing about coding style is to keep your source consistent.
Line 6: Line 6:
** Brief description
** Brief description
** Author
** Author
-
** Version
+
** Version (Optional)
* Tab/blank space indention: Using once method and keep consistent for the component
* Tab/blank space indention: Using once method and keep consistent for the component
** 4 spaces
** 4 spaces
Line 13: Line 13:
** one tab
** one tab
* Write comments appropriately  
* Write comments appropriately  
-
**
+
** Comments for functional block but not for code line
-
* Separate code line if …
+
** 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
* Deal with “()” and “{}” correctly
-
* Naming, naming …
+
** 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
* Pre-release test
 +
** Memory Usage Check Tool: Valgrind
 +
** Static Code Check Tool: K7
 +
** Checkpatch.pl

Latest revision as of 01:49, 10 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
Retrieved from "http://wiki.meego.com/Quality/TestSuite/MCTS/Code_style_common_rule"
Personal tools