ccf57e3d7a
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1373 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
87 lines
3.3 KiB
Plaintext
87 lines
3.3 KiB
Plaintext
Coding Style for Fail*
|
|
======================
|
|
|
|
You may violate/break any of the following rules if you have a good reason to
|
|
do so, e.g., if readability is notably enhanced.
|
|
|
|
For Python code, try to stick to <http://www.python.org/dev/peps/pep-0008>.
|
|
Especially use 4 spaces per indentation level, and don't mix tabs and spaces
|
|
for indentation.
|
|
|
|
The following style rules apply to C/C++/AspectC++ code:
|
|
|
|
- Language (comments, SVN commit messages, "temporary" stuff): English
|
|
(without exception)
|
|
|
|
- Naming conventions:
|
|
* Source files: .cc (Source), .hpp (Header), .ah (Aspect Header), MixedCase
|
|
* Namespaces: lowercase
|
|
* Classes, (global) functions: MixedCase, starting with uppercase letter
|
|
* Public members: MixedCase, starting with lowercase letter
|
|
* Private & protected members: starting with "m_"
|
|
* Global Variables: starting with "g_"
|
|
* Preprocessor macros: uppercase
|
|
- Include guard for MyFooBar.hpp: __MY_FOO_BAR_HPP__
|
|
* Constant variables: uppercase
|
|
* (no convention for local variables)
|
|
* typedefs: lowercase, underscores (good_name_t)
|
|
|
|
- Comments:
|
|
* Doxygen comments:
|
|
- In detail for all public members (parameters, return value, side
|
|
effects, ...)
|
|
- (At least) Briefly for private/protected members
|
|
- At the top of each (aspect) header file: @brief
|
|
- For each complex data type (and its elements)
|
|
* Explain *nontrivial* program logic not only by describing the "what's
|
|
happening here", but also the "why are we doing it this way".
|
|
* Use "normal" C/C++ comments within functions (//, /**/).
|
|
* No author names, creation dates, change logs etc. in source files.
|
|
That's why we're using a VCS.
|
|
|
|
- Formatting:
|
|
* Indentation: 1 tab (tabstop at 4 spaces)
|
|
- may be relaxed / mixed with spaces for better readability of
|
|
multi-line statements, e.g.:
|
|
<TAB>cout << "The counter value is: "
|
|
<TAB> << value;
|
|
<TAB>if (first_looong_condition &&
|
|
<TAB> second_looong_condition) {
|
|
<TAB><TAB>...
|
|
* Preprocessor directives start in column 1.
|
|
* Max. line length: 100 characters.
|
|
* "public"/"private"/"protected" has the same identation as its surrounding
|
|
"class Foo" statement (we'd waste one indentation level for every class
|
|
definition otherwise):
|
|
class Foo {
|
|
public:
|
|
<TAB>void doSomething();
|
|
};
|
|
Similarly (and for the same reason) for namespaces and switch/case
|
|
statements:
|
|
switch (foo) {
|
|
case 1:
|
|
<TAB>...
|
|
}
|
|
* Compound statements (blocks): <Space>+'{' in the same line as its
|
|
governing control structure (if, while, for, switch, try) or
|
|
namespace/class definition:
|
|
if (something) {
|
|
<TAB>...
|
|
}
|
|
* Method/Function definitions are an exception to this ('{' in a new line):
|
|
Definition: | Declaration:
|
|
void myFunction(int i) | void myFunction(int i);
|
|
{ |
|
|
<TAB>... |
|
|
} |
|
|
* Control structure tokens ("if", "try", for, ...) are followed by a
|
|
single space for better disambiguation from function definitions:
|
|
if (...) {
|
|
<TAB>...
|
|
} else if (...) {
|
|
<TAB>...
|
|
} else {
|
|
<TAB>...
|
|
}
|