/
CODING_STYLE.txt
75 lines (55 loc) · 2.3 KB
/
CODING_STYLE.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
The following coding style is used in Orocos:
Text Formatting
---------------
* NO TABS ANYWHERE, use spaces
* Indentation width is 4
* Use Namespaces instead of class/function prefixes
* upper/lowercase convention :
functionNameExample
vs ClassNameExample
vs variableNameExample
* Static class methods start with uppercase
Documentation
-------------
* Documentation is generated by Doxygen from code comments.
A code comment is placed above the function/variable/class and is formed
as
/**
* Short description.
* More elaborate description
* over multiple lines.
*
* @param par1 First parameter meaning.
* @param par2 Second parameter meaning.
* @return Return meaning.
*/
Take a good look at punctuation (.). All valid Doxygen tags are allowed.
* At least the class type must be documented, or the class is not included
in the documentation.
* Dia is the favored format for storing diagrams.
* American spelling is favored (not favoured :-) over Brittish spelling.
Inlining / performance
-----------------------
* Sometimes, a function is so small, it can be inlined. Examples are :
empty destructors, simple inspectors ( getX() ), constructors. Such
functions go in the header file instead of the implementation file.
If you want to separate implementation from interface, use a separate
abstract class with all functions pure virtual. A function
which is virtual can never be inlined, but to reduce maintenance, can
be placed in the header. Commands and Conditions fall into this category.
Since construction of objects (even statical allocated) can cause
performance penalties, inlining constructors is advised for empty body
constructors.
Templates
----------
* Each templated class must reside completely in the header file. Templates
can not be compiled seperately. The whole file, with implementation,
must be included.
* All template parameters must be typedef'ed to a meaningfull common
type (like iterator, value_type, Aspect,...) following STL notation
if appropriate.
* Typedef in the header file common uses of templated classes
for the user. Examples are
typedef MultiVector<double,6> Double6D;
typedef ReportExporter<Property> PropertyExporter;
* Boost Concept checking is allowed for use in your template classes.