Coding Standard

(Difference between revisions)
Jump to: navigation, search
 
Line 1: Line 1:
The increasing number of contributors require that we clearly define coding rules and guidelines. Although for historical reasons the current code of Stellarium does not always comply to these rules, they now should be respected for any addition or modification of the code.
+
The increasing number of contributors require that we clearly define coding rules and guidelines. Although for historical reasons the current code of Stellarium does not always comply to these rules, they should now be respected for any addition or modification of the code.
 +
 
 +
== Stylistic Conventions ==
 +
Source code should use ASCII character set. Characters such as 'é' or 'ö' are not portable when hardcoded. Gettext translated strings should be used for such characters.
 +
Variable names and comments should be in english.
 +
 
 +
Class names are nouns, in mixed-case, with an initial upper-case letter and the first letter of each subsequent word capitalized (e.g. CoreFactory).
 +
Method names are verbs or nouns in mixed-case, starting with a lower-case letter (e.g. update() or addElement()).
 +
Methods that return a value should take the form getSize().
 +
The names of local variables should be in mixed case, starting with a lower-case letter (e.g. packetSize). This also applies to the formal parameters of methods. Do not use names starting with underscore.
 +
The names of macro or static final constants should be all upper-case words, separated by underscores (e.g. MIN_WIDTH).
 +
 
 +
Indentation should be done with tabs, not spaces. This enables each developers to use his favorite indent size without changing the code.
 +
 
 +
Use blank lines as follows:
 +
  • 1 between methods, before (block or single line) comment
 +
  • 1 between logical sections of a method
 +
  • 2 between sections of a source file
 +
 
 +
Use the following layout for braces:
 +
void MyClass::myMethod(int x)
 +
{
 +
  if (x>10)
 +
  {
 +
      cout << "You won." << endl;
 +
  }
 +
}
  
== Indentation ==
 
  
 
== Comments ==
 
== Comments ==

Revision as of 12:11, 19 September 2006

The increasing number of contributors require that we clearly define coding rules and guidelines. Although for historical reasons the current code of Stellarium does not always comply to these rules, they should now be respected for any addition or modification of the code.

Contents

Stylistic Conventions

Source code should use ASCII character set. Characters such as 'é' or 'ö' are not portable when hardcoded. Gettext translated strings should be used for such characters. Variable names and comments should be in english.

Class names are nouns, in mixed-case, with an initial upper-case letter and the first letter of each subsequent word capitalized (e.g. CoreFactory). Method names are verbs or nouns in mixed-case, starting with a lower-case letter (e.g. update() or addElement()). Methods that return a value should take the form getSize(). The names of local variables should be in mixed case, starting with a lower-case letter (e.g. packetSize). This also applies to the formal parameters of methods. Do not use names starting with underscore. The names of macro or static final constants should be all upper-case words, separated by underscores (e.g. MIN_WIDTH).

Indentation should be done with tabs, not spaces. This enables each developers to use his favorite indent size without changing the code.

Use blank lines as follows:

 • 1 between methods, before (block or single line) comment
 • 1 between logical sections of a method
 • 2 between sections of a source file

Use the following layout for braces: void MyClass::myMethod(int x) {

  if (x>10)
  {
     cout << "You won." << endl;
  }

}


Comments

Low-level C code

Translatable strings

Personal tools
Namespaces
Variants
Actions
in this wiki
other languages
Toolbox