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 should now 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 ==
+
=== 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.  
+
* 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.
+
* 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).
+
* 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()).
+
* 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().
+
* 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 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).
+
* 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.
+
* 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:
+
* Use blank lines as follows:
  • 1 between methods, before (block or single line) comment
+
** 1 between methods, before (block or single line) comment
  • 1 between logical sections of a method
+
** 1 between logical sections of a method
  • 2 between sections of a source file
+
** 2 between sections of a source file
  
Use the following layout for braces:
+
* Use the following layout for braces:
void MyClass::myMethod(int x)
+
void MyClass::myMethod(int x)
{
+
{
  if (x>10)
+
    if (x>10)
  {
+
    {
      cout << "You won." << endl;
+
      cout << "You won." << endl;
  }
+
    }
}
+
}
  
  
== Comments ==
+
=== Comments ===
  
== Low-level C code ==
+
=== Low-level C code ===
  
== Translatable strings ==
+
=== Translatable strings ===

Revision as of 12:22, 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