codingConventions.doxygen   codingConventions.doxygen 
skipping to change at line 30 skipping to change at line 30
/*! /*!
@page codingStyle Coding Style Conventions in Stellarium @page codingStyle Coding Style Conventions in Stellarium
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 respec ted 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 respec ted for any addition or modification of the code.
@section stylistic_conventions_sec Stylistic Conventions @section stylistic_conventions_sec Stylistic Conventions
<ul> <ul>
<li>Source code should use ASCII character set. Characters such as 'é' or 'ö' are not portable when hard-coded. Gettext translated strings should be used for such characters. <li>Source code should use ASCII character set. Characters such as 'é' or 'ö' are not portable when hard-coded. Gettext translated strings should be used for such characters.
<li>Variable names and comments should be in English. <li>Variable names and comments should be in English.
<li>Class names are nouns, in mixed-case, with an initial upper-case lette <li>Class names are nouns, in mixed-case, with an initial upper-case
r and the first letter of each subsequent word capitalized (e.g. CoreFactory letter and the first letter of each subsequent word capitalized (e.g. CoreF
). actory).
<li>Method names are verbs or nouns in mixed-case, starting with a lower-c ase letter (e.g. update() or addElement()). <li>Method names are verbs or nouns in mixed-case, starting with a lower-c ase letter (e.g. update() or addElement()).
<li>Methods that return a value should take the form getSize(). <li>Methods that return a value should take the form getSize().
<li>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 parame ters of methods. Do not use names starting with underscore. <li>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 parame ters of methods. Do not use names starting with underscore.
<li>The names of macro or static const should be all upper-case words, sep arated by underscore: <li>The names of macro or static const should be all upper-case words, sep arated by underscore:
@code @code
#define MIN_WIDTH 3 #define MIN_WIDTH 3
static const QString VERSION = "0.10.1"; static const QString VERSION = "0.10.1";
@endcode @endcode
<li>Indentation should be done with tabs, not spaces. This allows each dev elopers to use his favorite indent size without changing the code. <li>Indentation should be done with tabs, not spaces. This allows each dev elopers to use his favorite indent size without changing the code.
<li>When wrapping lines from long function calls, where the wrapped line d oes not start at the same level of indentation as the start of the function call, tab up to the start of the function call, and then use spaces to the opening parenthesis. <li>When wrapping lines from long function calls, where the wrapped line d oes not start at the same level of indentation as the start of the function call, tab up to the start of the function call, and then use spaces to the opening parenthesis.
skipping to change at line 60 skipping to change at line 61
if (x>10) if (x>10)
{ {
cout << "You won." << endl; cout << "You won." << endl;
} }
} }
@endcode @endcode
<li>Use blank lines as follows: <li>Use blank lines as follows:
<ul> <ul>
<li>1 between methods, before (block or single line) comment <li>1 between methods, before (block or single line) comment
<li>1 between logical sections of a method <li>1 between logical sections of a method
<li>2 between sections of a source le <li>2 between sections of a source file
</ul> </ul>
<li>@em enums should follow the QT conventions. i.e. CamelCase with First letter capitalization for both enum type and enum values. Document with do xygen. The <b>//!\< </b>tag can be used to add descriptions on the same lin e as an enum value, e.g. <li>@em enums should follow the QT conventions. i.e. CamelCase with First letter capitalization for both enum type and enum values. Document with do xygen. The <b>//!\< </b>tag can be used to add descriptions on the same lin e as an enum value, e.g.
@verbatim @verbatim
//! @enum EnumName Here is a description of the enum //! @enum EnumName Here is a description of the enum
enum EnumName enum EnumName
{ {
EnumValueOne, //!< Some doxygen description of EnumValueOne EnumValueOne, //!< Some doxygen description of EnumValueOne
EnumValueTwo, //!< Some doxygen description of EnumValueTwo EnumValueTwo, //!< Some doxygen description of EnumValueTwo
EnumValueThree //!< Some doxygen description of EnumValueThree EnumValueThree //!< Some doxygen description of EnumValueThree
}; };
 End of changes. 2 change blocks. 
4 lines changed or deleted 4 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/