1 | <HTML> |
---|
2 | <TITLE> |
---|
3 | </TITLE> |
---|
4 | <!-- Changed by: Katsuya Amako, 2-Dec-1998 --> |
---|
5 | |
---|
6 | <BODY> |
---|
7 | <TABLE WIDTH="100%"><TR> |
---|
8 | <TD> |
---|
9 | </TD> |
---|
10 | |
---|
11 | <TD ALIGN="Right"> |
---|
12 | </TD> |
---|
13 | </TR></TABLE> |
---|
14 | <P> |
---|
15 | |
---|
16 | <BR><BR> |
---|
17 | <P ALIGN="Center"> |
---|
18 | <FONT SIZE="+4" COLOR="#238E23"> |
---|
19 | <B>2. Code Convention</B> |
---|
20 | </FONT> |
---|
21 | <BR><BR> |
---|
22 | |
---|
23 | <HR ALIGN="Center" SIZE="7%"> |
---|
24 | <BR><BR> |
---|
25 | |
---|
26 | |
---|
27 | <!-- ============================================== Section --> |
---|
28 | "A major benefit of object-oriented programming languages like |
---|
29 | C++ is the degree of reuse that can be achieved in |
---|
30 | well-engineered systems. A high degree of reuse means that |
---|
31 | far less code must be written for each new application; |
---|
32 | consequently, that is far less code to maintain." (G.Booch). |
---|
33 | <P> |
---|
34 | The set of rules listed here are the only 'imposed' rules which have |
---|
35 | been adopted for the development of Geant4. We think they might become |
---|
36 | useful also for those users who will develope C++ code for applications |
---|
37 | related to Geant4 and, why not?, in general ! |
---|
38 | <P> |
---|
39 | |
---|
40 | <H2>2.1 Introduction</H2> |
---|
41 | |
---|
42 | Geant4 as object-oriented toolkit is thought to be an integration of |
---|
43 | components (sets of classes) which are specific to the HEP applications |
---|
44 | or part of general foundation class libraries, math libraries |
---|
45 | (commercial or free) already implemented and distributed world-wide, |
---|
46 | useful as building blocks for a wide variety of applications. Even |
---|
47 | within HEP, the reusability of object-oriented software across |
---|
48 | different laboratories and between different experiments will be |
---|
49 | essential. |
---|
50 | <P> |
---|
51 | As an object-oriented toolkit, Geant4 can be certainly extended and |
---|
52 | refined by physicists and experts all over the world, who may have used |
---|
53 | or will use their own coding conventions and rules, different from each |
---|
54 | others. |
---|
55 | It is and has been then important not to impose too fixed rules or |
---|
56 | style-conventions for a world-wide collaboration like GEANT4, but just |
---|
57 | flexible and adequate guidelines for programming and coding styles. |
---|
58 | <P> |
---|
59 | "C++ was designed to support data abstraction and object-oriented |
---|
60 | programming in addition to traditional C programming techniques. |
---|
61 | It was not meant to force any particular programming style upon |
---|
62 | all users" (B.Stroustrup). |
---|
63 | <P> |
---|
64 | |
---|
65 | <HR> |
---|
66 | <H2>2.2 Programming guidelines</H2> |
---|
67 | |
---|
68 | The programming guidelines are the ones which refer to the way of using |
---|
69 | the features of the programming languages. They have to do with things |
---|
70 | like the adhesion to the object oriented paradigm (data-hiding, |
---|
71 | encapsulation, etc ...), the performance and portability. |
---|
72 | <P> |
---|
73 | |
---|
74 | <UL> |
---|
75 | <LI>Every class should have at least one constructor and a |
---|
76 | destructor even if it does nothing or is defined to do nothing. |
---|
77 | <P> |
---|
78 | If a class does not have a constructor there is no guarantee of |
---|
79 | how objects of that class will be initialized, whilst data |
---|
80 | members should be explicitly initialized therein. When the |
---|
81 | constructor dynamically allocates memory, a destructor must be |
---|
82 | added to return the memory to the free pool when an object gets |
---|
83 | cleaned up. |
---|
84 | <P> |
---|
85 | <LI>Each class should have an assignment operator:<BR> |
---|
86 | <KBD>ClassName& operator=(const ClassName&)</KBD><BR> |
---|
87 | and a copy constructor:<BR> |
---|
88 | <KBD>ClassName(const ClassName&)</KBD><BR> |
---|
89 | when allocating subsidiary data structures on the heap or |
---|
90 | consume any other kind of shared resources. |
---|
91 | <P> |
---|
92 | The assignment operator is called when one instance of a class |
---|
93 | is assigned to another. |
---|
94 | The copy constructor defines the behaviour of the class when it |
---|
95 | is passed by value as an argument, returned by value from a |
---|
96 | function, or used to initialize one instance with the value of |
---|
97 | another class instance. Defining this constructor, all the class |
---|
98 | objects are copied properly. When it doesn't make sense to copy |
---|
99 | or assign instances of a given class, the copy constructor or |
---|
100 | the = operator should be made private. |
---|
101 | <P> |
---|
102 | <LI>Data members should be made private/protected and accessed by |
---|
103 | inline functions in order to best implement information-hiding. |
---|
104 | <P> |
---|
105 | Inline expansion avoids the overhead of a function call and can |
---|
106 | result in large savings of CPU time expecially if applied to |
---|
107 | member functions supporting public access to private data |
---|
108 | (allowing the maximum data-hiding for a required performance). |
---|
109 | <P> |
---|
110 | <LI>The use of global variables or functions should be avoided where |
---|
111 | possible, in order to respect encapsulation. |
---|
112 | <P> |
---|
113 | <LI>The use of friend classes should be avoided where possible. |
---|
114 | <P> |
---|
115 | To garantee the encapsulation of a base class is always |
---|
116 | preferable to use protected data over friends or public data |
---|
117 | and then use inheritance. |
---|
118 | <P> |
---|
119 | <LI>The use of type casting should be avoided. |
---|
120 | <P> |
---|
121 | Especially from <KBD>const*</KBD> or <KBD>const</KBD>, type |
---|
122 | casting may be dangerous |
---|
123 | for data-hiding. In addition pointers should not be cast to int |
---|
124 | for portability reasons. |
---|
125 | <P> |
---|
126 | <LI>Hard-coded numbers within the code must be avoided. |
---|
127 | <P> |
---|
128 | For portability and maintainability reasons. The use of costants |
---|
129 | (<KBD>const</KBD>) is a valid solution. |
---|
130 | <P> |
---|
131 | <LI>Instead of the raw C types, the G4 types should be used. |
---|
132 | <P> |
---|
133 | For the basic numeric types (int, float, double, etc ...), |
---|
134 | different compilers and different platforms provide different |
---|
135 | value ranges. In order to assure portability, the use of G4int, |
---|
136 | G4float, G4double, which are base classes globally defined is |
---|
137 | preferable. G4 types implement the right generic type for a |
---|
138 | given architecture. |
---|
139 | </UL> |
---|
140 | <P> |
---|
141 | |
---|
142 | <HR> |
---|
143 | <H2>2.3 Coding-style conventions</H2> |
---|
144 | |
---|
145 | The coding-style guidelines are the ones which refer to the editing |
---|
146 | styles of the source code. They have to do with things like the code |
---|
147 | maintainability and readability. |
---|
148 | <P> |
---|
149 | |
---|
150 | <UL> |
---|
151 | <LI>The public, protected and private keywords must be used |
---|
152 | explicitly in the class declaration in order to make easier |
---|
153 | code readability. |
---|
154 | <P> |
---|
155 | <LI>English and self-explaining names for constants, variables and |
---|
156 | functions should be used for code readability. |
---|
157 | <P> |
---|
158 | Possibly avoid the use of underscore "_" characters within |
---|
159 | variables or function names (ex. <KBD>theTotalEnergy, |
---|
160 | SetEnergyTable(), GetTrackPosition()</KBD>, ...). |
---|
161 | <P> |
---|
162 | <LI>The code must be properly indented (ex. 2 characters indentation |
---|
163 | when inside a control structure) for readability reasons. |
---|
164 | <P> |
---|
165 | <LI>Each GEANT4 class name should begin with G4 |
---|
166 | <P> |
---|
167 | (ex. <KBD>G4Material, G4GeometryManager, G4ProcessVector</KBD>, ...) |
---|
168 | to keep an homogeneous naming style for GEANT4 specific classes. |
---|
169 | <P> |
---|
170 | <LI>Each header file should contain only one or related class |
---|
171 | declarations. |
---|
172 | <P> |
---|
173 | For maintainability reasons and to make easier retrieval of |
---|
174 | classes' definitions across each category. |
---|
175 | <P> |
---|
176 | <LI>Each class implementation source code should go into a single |
---|
177 | source file. |
---|
178 | <P> |
---|
179 | For maintainability reasons and to make easier retrieval of |
---|
180 | classes' implementations across each category. |
---|
181 | <P> |
---|
182 | <LI>Each header file must be protected from multiple inclusions. |
---|
183 | <P> |
---|
184 | In order to avoid multiple declarations and circular dependences |
---|
185 | in the code. Ex.: |
---|
186 | <PRE> |
---|
187 | #ifndef NAME_HH |
---|
188 | #define NAME_HH |
---|
189 | ... |
---|
190 | #endif |
---|
191 | </PRE> |
---|
192 | |
---|
193 | <LI>Each file should contain a short header about the author, |
---|
194 | updates (CVS) and date. |
---|
195 | <P> |
---|
196 | All files should begin with:<BR> |
---|
197 | <KBD> // $Id: codeConvention.html,v 1.2 1998/12/02 03:50:59 amako Exp $</KBD> |
---|
198 | and a half line comment with the name of the original author, |
---|
199 | update notes and dates. The <KBD>$Id: codeConvention.html,v 1.2 1998/12/02 03:50:59 amako Exp $</KBD> will expand to filename |
---|
200 | and last updater in CVS. |
---|
201 | </UL> |
---|
202 | <P> |
---|
203 | |
---|
204 | <HR> |
---|
205 | <H2>2.4 Coding-style for writing a Geant4 application </H2> |
---|
206 | <UL> |
---|
207 | <I> Style to adopt to write a Geant4 main application.</I> |
---|
208 | </UL> |
---|
209 | |
---|
210 | <HR> |
---|
211 | <H2>2.5 Programming Suggestions learned from experience</H2> |
---|
212 | |
---|
213 | Here is a list of rules/hints which we could collect after all |
---|
214 | periodical sessions of QA/QC on the developed code. These "hints" have |
---|
215 | been made public to Geant4 developers in order to avoid the most common |
---|
216 | mistakes and improve the quality of the code. |
---|
217 | <P> |
---|
218 | |
---|
219 | <UL> |
---|
220 | <LI>Initialize all data members of a class in each constructor |
---|
221 | (pointers, <KBD>G4ints</KBD>, etc.) |
---|
222 | <P> |
---|
223 | Bugs related to this problem are extremely difficult to track |
---|
224 | down ! |
---|
225 | <P> |
---|
226 | <LI>Do not insert items allocated on the heap into value-based |
---|
227 | collections (Or, at least, preserve the pointer for deletion) |
---|
228 | <P> |
---|
229 | <LI>Properly destruct objects |
---|
230 | <P> |
---|
231 | In particular, remember to delete items of a pointer based |
---|
232 | collection which were allocated on the heap. |
---|
233 | <P> |
---|
234 | <LI>Inline short and frequently used member functions |
---|
235 | <P> |
---|
236 | Define inlined functions in the .icc file and check that the |
---|
237 | compiler is effectively inlining them (using the proper |
---|
238 | compiler options). |
---|
239 | <P> |
---|
240 | <LI>A member function doing allocations on the heap may leak memory |
---|
241 | if the user invokes the function several times |
---|
242 | <P> |
---|
243 | Check if allocation was done already. |
---|
244 | <P> |
---|
245 | <LI>Access of elements of the RWTPtrOrderedVector collections |
---|
246 | <P> |
---|
247 | As of Tools.h++ V7.0.1: <BR> |
---|
248 | <KBD>operator()</KBD> fetches an element and does no bounds |
---|
249 | checking of the index.<BR> |
---|
250 | <KBD>operator[]</KBD> fetches an element and does bounds check. |
---|
251 | The library is only aware of insertions by <KBD>insert()</KBD> |
---|
252 | (and related functions). |
---|
253 | Therefore: |
---|
254 | <UL> |
---|
255 | <LI>filling the array by insert() and reading it with [] works; |
---|
256 | <LI>filling the array by () and reading it by () works; |
---|
257 | <LI>filling by [] does NOT work any more. |
---|
258 | </UL> |
---|
259 | <P> |
---|
260 | <LI>The return type of function main() |
---|
261 | <P> |
---|
262 | use the declaration int <KBD>main()</KBD> instead of |
---|
263 | <KBD>void main()</KBD> or <KBD>main()</KBD> |
---|
264 | (this "implicite int" will be excluded from the C++ standard |
---|
265 | soon). |
---|
266 | <P> |
---|
267 | <LI>Programs should return: <BR> |
---|
268 | <UL> |
---|
269 | <LI>0 or <KBD>EXIT_SUCCESS</KBD> on success; |
---|
270 | <LI>nonzero or <KBD>EXIT_FAILURE</KBD> on error. |
---|
271 | </UL> |
---|
272 | <P> |
---|
273 | <LI>Deletion of elements in pointer based collections |
---|
274 | <P> |
---|
275 | Items stored in pointer collections e.g. <KBD>RWTPtrOrderedVector</KBD> |
---|
276 | can be deleted by the method <KBD>clearAndDestroy()</KBD>. |
---|
277 | <P> |
---|
278 | <LI>Problems with classes that cannot be copied/assigned |
---|
279 | to/constructed etc. |
---|
280 | <P> |
---|
281 | It is best to make the corresponding member functions private. |
---|
282 | <P> |
---|
283 | <LI>Use const declarations whenever possible instead of numbers |
---|
284 | in the code |
---|
285 | <P> |
---|
286 | <LI>Avoid multiple return points in a method where possible |
---|
287 | <P> |
---|
288 | Methods with multiple return points cannot be inlined and |
---|
289 | some compilers (e.g. HP-CC) complain about this. |
---|
290 | <P> |
---|
291 | <LI>Use G4Exception to print an error message and exit the program |
---|
292 | <P> |
---|
293 | <LI>Use costants and units defined in <KBD>PhysicalConstants.h</KBD> and |
---|
294 | <KBD>SystemOfUnits.h</KBD> |
---|
295 | <P> |
---|
296 | Look inside those files in CLHEP/Units before defining local |
---|
297 | constants or putting hard-coded numbers in the code. |
---|
298 | <P> |
---|
299 | <LI>Do not code bit-wise operations within a word. Consider |
---|
300 | a word as atomic! |
---|
301 | </UL> |
---|
302 | |
---|
303 | |
---|
304 | <BR><BR> |
---|
305 | |
---|
306 | </BODY> |
---|
307 | </HTML> |
---|
308 | |
---|
309 | |
---|
310 | |
---|
311 | |
---|
312 | |
---|
313 | |
---|
314 | |
---|
315 | |
---|