| 2 |
bj |
1 |
Andreas Bærentzen,
|
|
|
2 |
December 2001
|
|
|
3 |
|
|
|
4 |
----------------------------------------------------------------------
|
|
|
5 |
CODING CONVENTIONS
|
|
|
6 |
----------------------------------------------------------------------
|
|
|
7 |
|
|
|
8 |
Coding conventions are very important if the source code is to remain
|
|
|
9 |
legible and tidy. Very strict conventions, however, will require too
|
|
|
10 |
much work of the programmer, and (if the programmer is myself) he will
|
|
|
11 |
start to ignore some of the conventions in order to do things more
|
|
|
12 |
quickly, and then the card house topples.
|
|
|
13 |
|
|
|
14 |
Nothing that imposes too much work should be made a coding
|
|
|
15 |
convention. For instance, a standard comment before each function
|
|
|
16 |
definition sounds like a good idea, but even with a template, it is
|
|
|
17 |
cumbersome to add and maintain these chunks of text, so I choose to
|
|
|
18 |
omit them.
|
|
|
19 |
|
|
|
20 |
The philosophy behind the conventions below is that they should simply
|
|
|
21 |
be standard ways of doing what a programmer does anyway and that they
|
|
|
22 |
should add only very little extra work.
|
|
|
23 |
|
|
|
24 |
USE OF CASE AND SPECIAL CHARACTERS
|
|
|
25 |
------------------------------
|
|
|
26 |
|
|
|
27 |
* Abbreviations are used only where the names would otherwise be
|
|
|
28 |
ludicrously long.
|
|
|
29 |
|
|
|
30 |
* Names of constants are all uppercase letters. Underscores are used to
|
|
|
31 |
combine words, e.g. `MAX_LEVEL'
|
|
|
32 |
|
|
|
33 |
* Names of classes and other new types are in lower case but
|
|
|
34 |
inter-capitalized, e.g. `class BoneMachine'
|
|
|
35 |
|
|
|
36 |
* The names of functions are lower case. Words are combined with
|
|
|
37 |
underscores, e.g. `int get_max()'
|
|
|
38 |
|
|
|
39 |
FUNCTION NAMING
|
|
|
40 |
------------------------------
|
|
|
41 |
|
|
|
42 |
* Words used
|
|
|
43 |
|
|
|
44 |
The words `get' and `set' are used in the names of functions that
|
|
|
45 |
assigns or retrieves the value of some state variable in a class.
|
|
|
46 |
|
|
|
47 |
E.g.
|
|
|
48 |
|
|
|
49 |
get_level
|
|
|
50 |
set_level
|
|
|
51 |
|
|
|
52 |
The words `find', `remove', `insert' are used in the names of
|
|
|
53 |
functions that access a database.
|
|
|
54 |
|
|
|
55 |
E.g.
|
|
|
56 |
|
|
|
57 |
find_node
|
|
|
58 |
remove_node
|
|
|
59 |
insert_node
|
|
|
60 |
|
|
|
61 |
The word `create' is used in the name of a function that creates and
|
|
|
62 |
returns a member of a class, e.g.
|
|
|
63 |
|
|
|
64 |
create_inquirer
|
|
|
65 |
|
|
|
66 |
The word `inquirer' is used in the names of functions that access
|
|
|
67 |
data structures. E.g.
|
|
|
68 |
|
|
|
69 |
OctreeInquirer
|
|
|
70 |
|
|
|
71 |
COMMENTING
|
|
|
72 |
------------------------------
|
|
|
73 |
|
|
|
74 |
* Comments are used where appropriate. DOC++ comments are used
|
|
|
75 |
for all class members in .h files. There are no comments used
|
|
|
76 |
purely for aestethical or ``typographical'' reasons.
|
|
|
77 |
...
|
|
|
78 |
|
|
|
79 |
At some point I may add a standard file header. Could contain CVS
|
|
|
80 |
information perhaps.
|
|
|
81 |
|
|
|
82 |
FUNCTION ARGUMENTS
|
|
|
83 |
------------------------------
|
|
|
84 |
|
|
|
85 |
* Constructor arguments. If a class X contains a variable y that is
|
|
|
86 |
initialized in the contructor of X, then the argument to the
|
|
|
87 |
constructor should be _y, that is
|
|
|
88 |
|
|
|
89 |
X::X(_y): y(_y) {}
|
|
|
90 |
|
|
|
91 |
* Usually a function takes arguments that are constant and ``call by
|
|
|
92 |
reference'' arguments that may be modified. The constant arguments
|
|
|
93 |
should come first, then the modifiable. E.g.
|
|
|
94 |
|
|
|
95 |
foo(const MyClass&, int, float&);
|
|
|
96 |
|
|
|
97 |
has two constant arguments followed by a float which is passed by
|
|
|
98 |
reference.
|
|
|
99 |
|
|
|
100 |
FILE (NAMING) CONVENTIONS
|
|
|
101 |
------------------------------
|
|
|
102 |
|
|
|
103 |
* All classes that are not auxiliary (i.e. used only by one particular
|
|
|
104 |
other class) have a header file of their own.
|
|
|
105 |
|
|
|
106 |
* The name of the header file is that of the class + `.h'
|
|
|
107 |
|
|
|
108 |
* All non-auxiliary classes with one or more functions that are not
|
|
|
109 |
inline have a definition file of their own.
|
|
|
110 |
|
|
|
111 |
* The name of the definition file is that of the class + `.cc'
|
|
|
112 |
|
|
|
113 |
* The #define <macro> in the include guard uses the name of the file -
|
|
|
114 |
capitalized and with dot replaced by underscore. The macro name is
|
|
|
115 |
preceded by two underscores
|
|
|
116 |
|
|
|
117 |
E.g.
|
|
|
118 |
|
|
|
119 |
#ifndef __BONEMACHINE_H
|
|
|
120 |
#define __BONEMACHINE_H
|
|
|
121 |
|
|
|
122 |
... code ....
|
|
|
123 |
|
|
|
124 |
#endif
|
|
|
125 |
|