forked from thomasmoelhave/tpie
-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathCodingGuidelines.txt
149 lines (96 loc) · 4.32 KB
/
CodingGuidelines.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
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
******************************************
***
*** CodingGuidelines.txt
***
*** $Id: CodingGuidelines.txt,v 1.2 2005-11-09 12:07:55 thomasm Exp $
***
******************************************
Purpose of this document:
- To provide guidelines for how to write C++
code that is supposed to become part of
the TPIE project.
How to modify this document:
- Contact the person who is responsible for
the respective rule.
- If the change is approved, substitute your
initals for the initials of the previous
author.
- If necessary, update the list of maintainers
to include your name, initials, and e-mail address.
- Commit the changes (or have some member of
the TPIE project commit them).
Maintainers:
- Thomas Molhave (tm, thomasm@daimi.au.dk)
- Jan Vahrenhold (jv, jan.vahrenhold@cs.tu-dortmund.de)
- Henrik Blunck (hb, blunck@madalgo.au.dk)
******************************************************************
Section 1. Documentation.
******************************************************************
1.1. Code has to be documented using doxygen (www.doxygen.org). (jv)
1.2. Comments have to be given at least for all public and protected
methods and attributes. (jv)
Additionally, doxygen compatible comments for private members as
well as for functions, enumeration types and header files are
encouraged. (hb)
1.3. Old-C-style comments ( /* */ ) shall not be used. (jv)
1.4. Comments for classes, methods and functions shall be written using
the "three-slash" style followed and preceeded by a line
of slashes. (hb)
Example:
/////////////////////////////////////////////////////////
///
/// This class serves as an example.
///
/////////////////////////////////////////////////////////
1.5. Javadoc-style comments may be used for commenting
attributes and enumerations. (jv)
Example:
/** This is a sample attribute. */
int attribute;
1.6. An empty expression, e.g., an empty destructor should
be commented using " // Do nothing." (jv)
******************************************************************
Section 2. Naming Convention
******************************************************************
2.1. Class names shall be all-lowercase using an underscore
to separate parts. (tm)
Example: class foo_bar_base { ... }
2.2. Method names shall be all-lowercase using an underscore
to separate parts. (tm)
Example: int foo_bar();
2.3. Names of attributes, parameters, and variables shall be
starting with a lowercase letter and use uppercase letters
to seperate parts. (jv)
Example: int myLocalVariable;
2.4. Instance and class attributes shall be prefixed by "m_". (jv)
Example: short m_anAttribute;
2.5. The use of namespacing shall be enforced. The namespace
for the TPIE-project is "tpie::". (tm)
2.6. Do not import symbols into the global namespace (this prohibits
many uses of the "using" keyword). (tm)
******************************************************************
Section 3. Writing Efficient Code
******************************************************************
3.1. Use const modifiers for methods and parameters wherever
possible. (tm)
******************************************************************
Section 4. Class Design and Layout
******************************************************************
4.1. The components of a class shall appear in the following
order: public - protected - private (jv)
4.2. Bodies longer than 6 lines of code shall be put in an
inline file (.inl) which is included after the
class declaration. (tm)
4.3. The "at-most-one-class-per-file" rule shall be enforced. (jv)
4.4. Attributes shall not be public. Every attribute shall
be accompanied by a "put"- and "get"-method. The name
of such a method is the name of the attribute prefixed
by "put_" or "get_" (using the naming convention, parts
of the attribute name are sepearated by underscores).
Read-only attributes shall be accessed by a method that
is named just like the attribute. (jv)
Example:
int get_my_attribute() const;
void put_my_attribtue(int myAttribute);
int my_readonly_attribute() const;
******************************************************************