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
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<title>Crazy Eddies GUI System: Coding Standards in use for CEGUI</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<link href="doxygen.css" rel="stylesheet" type="text/css"/>
</head>
<body>
<!-- Generated by Doxygen 1.7.4 -->
<script type="text/javascript">
function hasClass(ele,cls) {
return ele.className.match(new RegExp('(\\s|^)'+cls+'(\\s|$)'));
}
function addClass(ele,cls) {
if (!this.hasClass(ele,cls)) ele.className += " "+cls;
}
function removeClass(ele,cls) {
if (hasClass(ele,cls)) {
var reg = new RegExp('(\\s|^)'+cls+'(\\s|$)');
ele.className=ele.className.replace(reg,' ');
}
}
function toggleVisibility(linkObj) {
var base = linkObj.getAttribute('id');
var summary = document.getElementById(base + '-summary');
var content = document.getElementById(base + '-content');
var trigger = document.getElementById(base + '-trigger');
if ( hasClass(linkObj,'closed') ) {
summary.style.display = 'none';
content.style.display = 'block';
trigger.src = 'open.png';
removeClass(linkObj,'closed');
addClass(linkObj,'opened');
} else if ( hasClass(linkObj,'opened') ) {
summary.style.display = 'block';
content.style.display = 'none';
trigger.src = 'closed.png';
removeClass(linkObj,'opened');
addClass(linkObj,'closed');
}
return false;
}
</script>
<div id="top">
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Crazy Eddies GUI System <span id="projectnumber">0.7.6</span></div>
</td>
</tr>
</tbody>
</table>
</div>
<div id="navrow1" class="tabs">
<ul class="tablist">
<li><a href="index.html"><span>Main Page</span></a></li>
<li class="current"><a href="pages.html"><span>Related Pages</span></a></li>
<li><a href="namespaces.html"><span>Namespaces</span></a></li>
<li><a href="annotated.html"><span>Classes</span></a></li>
<li><a href="files.html"><span>Files</span></a></li>
</ul>
</div>
</div>
<div class="header">
<div class="headertitle">
<div class="title">Coding Standards in use for <a class="el" href="namespaceCEGUI.html" title="Main namespace for Crazy Eddie's GUI Library.">CEGUI</a> </div> </div>
</div>
<div class="contents">
<div class="textblock"><dl class="author"><dt><b>Author:</b></dt><dd>Paul D Turner</dd></dl>
<p>This page details the coding standards and general style that should be employed when working on code for the <a class="el" href="namespaceCEGUI.html" title="Main namespace for Crazy Eddie's GUI Library.">CEGUI</a> project. I am well aware that some of the existing code does not comply with these standards; though all new code should now be written to comply, and older code will be migrated over a period of time.</p>
<h2><a class="anchor" id="code_standards_sec_1"></a>
Files</h2>
<p>Here we describe the requirements relating to files; their naming, layout and arrangement on disk.</p>
<h3><a class="anchor" id="code_standards_sec_1_1"></a>
Naming and Directory Layout</h3>
<p>This section contains some general guidelines on naming and arranging files.</p>
<ul>
<li>The source code in general exists in two groups; the library code itself, and code for the sample applications:<ul>
<li>The library code, beneath the <b>cegui</b> directory, is contained within dual directory trees - one beneath the <b>src</b> directory to contain all the implementation .cpp files, and one beneath the <b>include</b> directory to contain all the header .h files. Within these directories, there should be a seperate subdirectory for each group of modules or subcomponents within the system. For example there are subdirectories for <b>RendererModules</b> and <b>XMLParserModules</b> to hold the renderer module code and XML parser module code respectively; these directories then have further subdirectories for each individual module.</li>
<li>The sample code, beneath the <b>samples</b> directory, has individual directories for each sample application. The implementation and header files for the sample should both appear together in this directory; there should be no separate <b>src</b> and <b>include</b> subdirectories for the samples.</li>
</ul>
</li>
<li>File names should not contain spaces, although the use of the underscore is acceptable where neccessary.</li>
<li>File names should begin with the <a class="el" href="namespaceCEGUI.html" title="Main namespace for Crazy Eddie's GUI Library.">CEGUI</a> prefix and then have the initial letter of all other words captialised.</li>
<li>Files should generally be named after the class or module to which they relate. For example, the file <b>CEGUIMyClass.h</b> would be the main header for the class named <b>MyClass</b>.</li>
<li>Source files within <a class="el" href="namespaceCEGUI.html" title="Main namespace for Crazy Eddie's GUI Library.">CEGUI</a> should use the following convention:<ul>
<li>C++ header files should have the <b></b>.h file extension.</li>
<li>C++ source files should have the <b></b>.cpp file extension.</li>
<li>Lua source files should have the <b></b>.lua file extension.</li>
<li>Extra Doxygen documentation files should have the <b></b>.dox file extentsion.</li>
</ul>
</li>
</ul>
<h3><a class="anchor" id="code_standards_sec_1_2"></a>
General Structure and Layout</h3>
<ul>
<li>All source files are required to have the basic file header that can bee seen in existing files. The information in the header is the filename, the date the file was created, the name and email address of the person who created the file, and the standard copyright/license notice as follows: <div class="fragment"><pre class="fragment"><span class="comment">/*******************************************************************************</span>
<span class="comment"> Filename: <name of the file, including extension></span>
<span class="comment"> Created: <date the file was created></span>
<span class="comment"> Author: <name and email of the original file author></span>
<span class="comment">*******************************************************************************/</span>
<span class="comment">/***************************************************************************</span>
<span class="comment"> Copyright (C) 2004 - 2012 Paul D Turner & The CEGUI Development Team</span>
<span class="comment"></span>
<span class="comment"> Permission is hereby granted, free of charge, to any person obtaining</span>
<span class="comment"> a copy of this software and associated documentation files (the</span>
<span class="comment"> "Software"), to deal in the Software without restriction, including</span>
<span class="comment"> without limitation the rights to use, copy, modify, merge, publish,</span>
<span class="comment"> distribute, sublicense, and/or sell copies of the Software, and to</span>
<span class="comment"> permit persons to whom the Software is furnished to do so, subject to</span>
<span class="comment"> the following conditions:</span>
<span class="comment"></span>
<span class="comment"> The above copyright notice and this permission notice shall be</span>
<span class="comment"> included in all copies or substantial portions of the Software.</span>
<span class="comment"></span>
<span class="comment"> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,</span>
<span class="comment"> EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF</span>
<span class="comment"> MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.</span>
<span class="comment"> IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR</span>
<span class="comment"> OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,</span>
<span class="comment"> ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR</span>
<span class="comment"> OTHER DEALINGS IN THE SOFTWARE.</span>
<span class="comment"> ***************************************************************************/</span>
</pre></div></li>
</ul>
<ul>
<li>All header files should have include guards implemented via preprocessor <code>#ifdef/#endif</code> commands. We do not want any pragma rubbish used for this as it's worse than useless as far as being portable goes. The macro used to control the header should be based upon the filename.</li>
</ul>
<ul>
<li>Please ensure that all files have a newline at the end of them. Depending upon the layout of included files and various other things, not having a newline has the potential to cause code not to compile correctly - especially in relation to includes. Plus it gives loads of annoying warnings on gcc :)</li>
</ul>
<ul>
<li>Wherever possible preprocessor macros should <em>not be used</em>. Always prefer the use of an actual language construct (such as typedef or enum) over a preprocessor <code>#define</code>.</li>
</ul>
<ul>
<li>Wherever possible header files should contain Doxygen documentation for all classes, data and functions. There will be <em>very few</em>, if any, exceptions to this rule.</li>
</ul>
<ul>
<li>In source files, definitions of the various data groups and each member function should be separated by a line, thus: <div class="fragment"><pre class="fragment"><span class="comment">//----------------------------------------------------------------------------//</span>
</pre></div></li>
</ul>
<ul>
<li>Implementation code belongs in the implementation .cpp files, not in the header files. There are very few cases, such as for template implementation, where c++ code should appear in header files.</li>
</ul>
<ul>
<li>The general content of a header file should be in the following order:<ul>
<li>File header.</li>
<li>Include guard.</li>
<li>#include statements (grouped according to library where appropriate).</li>
<li>Preprocessor macro defines (especially try to avoid these in headers).</li>
<li>Class forward references.</li>
<li>Global declarations.</li>
<li>Class declarations.</li>
<li>Code implementaions - for example, for templatised functions.</li>
</ul>
</li>
</ul>
<ul>
<li>The general content of a source file should be in the following order:<ul>
<li>File header.</li>
<li>#include statements (grouped according to library where appropriate).</li>
<li>Preprocessor macro defines (avoid where possible).</li>
<li>Global definitions.</li>
<li>Class static data definitions.</li>
<li>Class member function definitions.</li>
</ul>
</li>
</ul>
<h2><a class="anchor" id="code_standards_sec_2"></a>
Code Style and Layout</h2>
<p>The following details the general code style and layout that must be used.</p>
<h3><a class="anchor" id="code_standards_sec_2_1"></a>
Naming Conventions for Types, Variables, Members and Constants</h3>
<ul>
<li>Preprocessor macro names should be all upper case with words separated by the underscore character. Wherever possible, do not use preprocessor macros. A general exception to this particular rule is the name of include guards which may have case matching that of the header filename.</li>
</ul>
<ul>
<li>All types (namespaces, classes, structs, typedefs and enums) should have descriptive names and use PascalCase; where each word of the name is capitalised - such as in <b>MyClass</b>.</li>
</ul>
<ul>
<li>Constants should be all upper case with words separated by an underscore, such as in <b>THIS_IS_CONSTANT</b>. Please note that this rule does also apply to class member constants and enumeration values.</li>
</ul>
<ul>
<li>Global variables should use camel case; where each word in the name is capitalised except the first word. Globals should be prefixed with <b>G_</b>. So if we had a global we want to call 'nastyVariable' it should be named <b>G_nastyVariable</b> - yes, it looks horrible, and hopefully it's horrible enough that you find another way!</li>
</ul>
<ul>
<li>Class member variables should be camel case; where each word in the name is capitalised except the first word, such as in <b>thisVariable</b>. Normal members should have the prefix <b>d_</b>, such as in <b>d_thisVariable</b>, while static members should have the prefix <b>s_</b>, such as in <b>s_anotherVariable</b>.</li>
</ul>
<ul>
<li>Class member functions should be camel case; where each word in the name is capitalised except the first word, such as in <b>theFunction</b>. Member functions do not use prefixes.</li>
</ul>
<ul>
<li>Local variables in functions should be all lower case with an underscore between words, such as in <b>word_count</b>.</li>
</ul>
<ul>
<li>Parameter names are treated the same as other local variables, so should be named all lower case with an underscore between words, such as in <b>char_count</b>.</li>
</ul>
<h3><a class="anchor" id="code_standards_sec_2_2"></a>
Code Formatting Style and Other Tips</h3>
<ul>
<li>Generally speaking no line should be more than 80 characters long.</li>
</ul>
<ul>
<li>Do not use actual tabs, insert spaces instead.</li>
</ul>
<ul>
<li>Tab spacing size should be 4.</li>
</ul>
<ul>
<li>Code within functions should be split into logical groups by the use of blank lines where appropriate. Generally any control structure (if, while, case, do and so on) should be both preceded and followed by a blank line.</li>
</ul>
<ul>
<li>When commenting, write the comment first; always put it before the line or block it pertains to. This helps to ensure the comment indicates the intent of the code that you then write, rather than parrotting what is obvious from the code, which tends to happen when adding comments afterwards - we can already see what the code <em>does</em>, what we're interested in is it's <em>purpose</em>; the why as opposed to the what.</li>
</ul>
<ul>
<li>Any and all braces opening a code block should be on their own line, and not attached to the control structure that came before. That is, like this: <div class="fragment"><pre class="fragment"><span class="keywordflow">if</span> (something == 1)
{
...
}
</pre></div> but not like this: <div class="fragment"><pre class="fragment"><span class="keywordflow">if</span> (something == 1) {
...
}
</pre></div></li>
</ul>
<ul>
<li>Class declarations should not have the protection level specifiers indented. It should be like this: <div class="fragment"><pre class="fragment"><span class="keyword">class </span>SomeClass
{
<span class="keyword">public</span>:
SomeClass();
};
</pre></div> rather than like this: <div class="fragment"><pre class="fragment"><span class="keyword">class </span>SomeClass
{
<span class="keyword">public</span>:
SomeClass();
};
</pre></div></li>
</ul>
<ul>
<li>Namespace content should not be indented; it wastes too much line space. It should be like this: <div class="fragment"><pre class="fragment"><span class="keyword">namespace </span>SomeNamespace
{
<span class="keyword">class </span>SomeClass
{
<span class="keyword">public</span>:
SomeClass();
</pre></div> as opposed to this: <div class="fragment"><pre class="fragment"><span class="keyword">namespace </span>SomeNamespace
{
<span class="keyword">class </span>SomeClass
{
<span class="keyword">public</span>:
SomeClass();
</pre></div></li>
</ul>
<ul>
<li>Switch case statements should not be indented, though the case code should. Any required braces should appear in line with the case to which they pertain, such as in: <div class="fragment"><pre class="fragment"><span class="keywordflow">switch</span> (somevar)
{
<span class="keywordflow">case</span> 1:
x = x + 1;
<span class="keywordflow">break</span>;
<span class="keywordflow">case</span> 2:
{
<span class="keywordtype">int</span> y = 2;
x = x + y;
<span class="keywordflow">break</span>;
}
}
</pre></div> It should not contain anything like you see here: <div class="fragment"><pre class="fragment"><span class="keywordflow">switch</span> (somevar)
{
<span class="keywordflow">case</span> 1:
x = x + 1;
<span class="keywordflow">break</span>;
<span class="keywordflow">case</span> 2:
{
<span class="keywordtype">int</span> y = 2;
x = x + y;
<span class="keywordflow">break</span>;
}
}
</pre></div></li>
</ul>
<ul>
<li>The general layout of a function definition (in the .cpp source file) should have the return type on the same line, such as this: <div class="fragment"><pre class="fragment">std::string SomeClass::getString(<span class="keyword">const</span> <span class="keywordtype">char</span>* c_str)
{
...
}
</pre></div></li>
</ul>
<ul>
<li>Use of single line code blocks both with or without braces for loop and condition constructs is allowed. Though generally you should prefer the form without braces. <div class="fragment"><pre class="fragment"><span class="comment">// This is preferred</span>
<span class="keywordflow">if</span> (something == <span class="keyword">true</span>)
doSomething();
<span class="comment">// Though this is fine, also</span>
<span class="keywordflow">if</span> (something_else == <span class="keyword">true</span>)
{
doSomethingElse();
}
</pre></div></li>
</ul>
<ul>
<li>Having multiple statements on a single line is not allowed, even for control structures. Each statement should be on its own line. Code should be like this: <div class="fragment"><pre class="fragment"><span class="keywordflow">if</span> (x == 0)
x = 1;
x = 2;
x += y;
</pre></div> Code should not be like this: <div class="fragment"><pre class="fragment"><span class="keywordflow">if</span> (x == 0) x = 1;
x = 2; x += y;
</pre></div></li>
</ul>
<ul>
<li>There should be a space between a control statement and its control expression. Use this: <div class="fragment"><pre class="fragment"><span class="keywordflow">if</span> (something)
x = y;
</pre></div> Not this: <div class="fragment"><pre class="fragment"><span class="keywordflow">if</span>(something)
x = y;
</pre></div></li>
</ul>
<ul>
<li>When calling a function, there should be no space between the function name and the parenthesis containing the arguments. So, like this: <div class="fragment"><pre class="fragment">an_object->callFunction(x, y, x);
</pre></div> Not like this: <div class="fragment"><pre class="fragment">an_object->callFunction (x, y, x);
</pre></div></li>
</ul>
<ul>
<li>There should generally not be spaces around parenthesis (unless otherwise excepted above). Code should look like this: <div class="fragment"><pre class="fragment">a = calculate((x + y) * z);
</pre></div> Not like this: <div class="fragment"><pre class="fragment">a = calculate( ( x + y ) * z );
</pre></div></li>
</ul>
<ul>
<li>There should be spaces both sides of virtually all operators, except the comma which just has one following it. An example of correct usage is: <div class="fragment"><pre class="fragment">a = calculate((x + y) * z);
b = doSomething(a, x, y);
</pre></div> Not anything like these: <div class="fragment"><pre class="fragment">a = calculate((x+y)*z);
b=doSomething(a,x , y);
</pre></div></li>
</ul>
<ul>
<li>When creating a pointer or reference variable the asterisk or ampersand should be attached to the type name not the variable name. These are correct: <div class="fragment"><pre class="fragment">SomeClass* class_ptr;
SomeClass& class_ref = an_object;
</pre></div> While these are not: <div class="fragment"><pre class="fragment">SomeClass *class_ptr;
AnotherClass * another_ptr;
SomeClass &class_ref = an_object;
</pre></div></li>
</ul>
<ul>
<li>When dereferencing a pointer or taking the address of some object, the asterisk or ampersand should be attached to the variable name, like this: <div class="fragment"><pre class="fragment">SomeClass& class_ref = *class_ptr;
a_ptr = &an_object;
</pre></div></li>
</ul>
<ul>
<li>String and/or character literals should not appear in production code; use constant definitions instead.</li>
</ul>
<ul>
<li>Magic numbers should not appear in production code; use constant definitions instead. In general the only number that may appear in production code is <code>0</code>.</li>
</ul>
<ul>
<li>Use of <code>NULL</code> is not allowed; use <code>0</code> instead. <code>NULL</code> is just a macro definition and does not exist in any other form in the C++ language, so it should not be used.</li>
</ul>
<ul>
<li>When defining class constructors, use of member initialiser lists is to be strongly preferred over the use of assignments in the constructor body.</li>
</ul>
<ul>
<li>Only use C++ style casts. C style casts should not be used. Or better yet, find a way not to use the cast at all! </li>
</ul>
</div></div>
<hr class="footer"/><address class="footer"><small>Generated on Sun Jan 22 2012 16:07:40 for Crazy Eddies GUI System by 
<a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/></a> 1.7.4 </small></address>
</body>
</html>
|
