1 karl 1.4.2.3 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2 <html><head>
3
4
5 <meta http-equiv="Content-Language" content="en-us">
6 <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"><title>PEP 221 - Pegasus Coding Conventions</title>
7
8 <link rel="stylesheet" href="http://www.opengroup.org/stylesheets/info1+margins.css"></head><body>
9
10 <hr>
11
12 <p align="center"><b><font size="4">Pegasus Enhancement Proposal (PEP)</font></b></p>
13 <p><b>PEP #:</b> 221</p>
14 <p><b>Title:</b> Pegasus Coding Conventions</p>
15 <p><b>Status:</b> Approved</p>
16 <p><b>Version History:</b></p>
17 <table bordercolordark="#666666" bordercolorlight="#CCCCCC" style="font-family: Arial;" border="1" cellspacing="1" width="100%">
18 <tbody><tr>
19 <th bgcolor="#cae6ca">Version</th>
20 <th bgcolor="#cae6ca">Date</th>
21 <th bgcolor="#cae6ca">Author</th>
22 karl 1.4.2.3 <th bgcolor="#cae6ca">Change Description</th>
23 </tr>
24 <tr>
25 <td align="center">1.0</td>
26 <td align="center">23 February 2005</td>
27 <td align="center">Roger Kumpf</td>
28 <td>Initial submittal, based on documents in pegasus/doc directory in CVS
29 (conventions.txt, portability.txt, CodeReviewNotes.txt, and DOCREMARKS).
30 </td>
31 </tr>
32 <tr>
33 <td align="center">1.1</td>
34 <td align="center">1 March 2005</td>
35 <td align="center">Roger Kumpf</td>
36 <td>Updated based on 3/1/05 architecture review comments.<br>
37 <em>Approved version (Ballot 95).</em></td>
38 </tr>
39 <tr>
40 <td align="center">2.0</td>
41 <td align="center">21 March 2005</td>
42 <td align="center">Roger Kumpf</td>
43 karl 1.4.2.3 <td>Opened up for additional conventions.</td>
44 </tr>
45 <tr>
46 <td align="center">2.1</td>
47 <td align="center">5 August 2005</td>
48 <td align="center">Roger Kumpf</td>
49 <td>Updated based on comments and architecture team discussions.</td>
50 </tr>
51 <tr>
52 <td align="center">2.2</td>
53 <td align="center">21 February 2006</td>
54 <td align="center">Roger Kumpf</td>
55 <td>Updated based on review comments.</td>
56 </tr>
57 <tr>
58 <td align="center">2.3</td>
59 <td align="center">24 February 2006</td>
60 <td align="center">Roger Kumpf</td>
61 <td>Updated based on review comments and architecture team discussion.</td>
62 </tr>
63 <tr>
64 karl 1.4.2.3 <td align="center">2.4</td>
65 <td align="center">10 March 2006</td>
66 <td align="center">Roger Kumpf</td>
67 <td>Updated based on ballot comments.<br>
68 <em>Approved version (Ballot 111).</em>
69 </td>
70 </tr>
71 <tr>
72 <td align="center">3.0</td>
73 <td align="center">10 March 2006</td>
74 <td align="center">Roger Kumpf</td>
75 <td>Opened up for additional conventions.</td>
76 </tr>
77 <tr>
78 <td align="center">3.1</td>
79 <td align="center">20 November 2008</td>
80 <td align="center">Roger Kumpf</td>
81 <td>Updated based on review comments.</td>
82 </tr>
83 <tr>
84 <td align="center">3.2</td>
85 karl 1.4.2.3 <td align="center">26 November 2008</td>
86 <td align="center">Roger Kumpf</td>
87 <td>Updated based on review comments.</td>
88 </tr>
89 <tr>
90 <td align="center">3.3</td>
91 <td align="center">4 December 2008</td>
92 <td align="center">Roger Kumpf</td>
93 <td>Updated based on review comments.<br>
94 <em>Approved version (Ballot 160).</em>
95 </td>
96 </tr>
97 <tr>
98 <td align="center">3.4</td>
99 <td align="center">22 January 2013</td>
100 <td align="center">Marek Szermutzky</td>
101 <td>Adding section on Unused's (variables,
102 arguments, values etc.)</td>
103 </tr>
104 <tr>
105 <td align="center">3.5</td>
106 karl 1.4.2.3 <td align="center">22 January 2013</td>
107 <td align="center">Marek Szermutzky</td>
108 <td>macro PEGASUS_FCT_EXECUTE_AND_ASSERT added</td>
109 </tr><tr>
110 <td style="vertical-align: top; text-align: center;">3.6<br>
111 </td>
112 <td style="vertical-align: top; text-align: center;">19 November 2013<br>
113 </td>
114 <td style="vertical-align: top;">Karl Schopmeyer<br>
115 </td>
116 <td style="vertical-align: top;">Add rule about defaults in switch constructs (see Formatting, 22)<br>
117 </td>
118 </tr>
119
120 </tbody></table>
121 <p> </p>
122 <hr>
123 <p><b>Abstract:</b> This document formalizes the Pegasus coding conventions.
124 </p>
125 <hr>
126
127 karl 1.4.2.3 <h2><font color="#000000">Definition of the Problem</font></h2>
128 <p><the use="" inconsistent="" styles="" is="" an="" impediment="" effective="" development="" and="" maintenance="" code.="" formalization="" of="" pegasus="" coding="" conventions="" may="" help="" to="" improve="" code="" consistency.=""></the></p>
129
130 <h2><font color="#000000">Proposed Solution</font></h2>
131 <p>The following items comprise the Pegasus coding conventions.</p>
132
133 <h3>Formatting</h3>
134 <ol>
135
136 <li>Indent by increments of four spaces. Indent comments
137 equally with the associated code.</li>
138 <li>Do not use tab characters.</li>
139 <li>Lines must not span more than 80 columns.</li>
140 <li>Remove trailing spaces at the end of a line.
141 (Note: This also applies to Makefiles, where trailing spaces may cause
142 unintended whitespace in generated files.)</li>
143 <li>Put opening brace on a line by itself, aligned with control keyword
144 or method signature.
145 Do this:
146 <pre><code> for (...)<br> {<br> }</code></pre>
147 Not this:
148 karl 1.4.2.3 <pre><code> for (...) {<br> }</code></pre>
149 Or this:
150 <pre><code> for (...)<br> {<br> }</code></pre>
151 </li>
152 <li>Use braces around the body of a control block (e.g., <code>if</code>,
153 <code>for</code>, or <code>while</code> statement), even if the body
154 contains just a single statement.
155 Do this:
156 <pre><code> for (...)<br> {<br> i++;<br> }</code></pre>
157 Not this:
158 <pre><code> for (...)<br> i++;</code></pre>
159 </li>
160 <li>Use a new line for <code>else</code> statements rather
161 than placing then on the same line as a preceding '<code>}</code>'.
162 Do this:
163 <pre><code> if (...)<br> {<br> i++;<br> }<br> else<br> {<br> j++;<br> }</code></pre>
164 Not this:
165 <pre><code> if (...)<br> {<br> i++;<br> } else<br> {<br> j++;<br> }</code></pre>
166 </li>
167 <li>Use normal indenting for parameters in a complex method signature:
168 <pre><code> void MyClass::myMethod(<br> const char* someReallyLongName,<br> const char* someOtherReallyLongName);</code></pre>
169 karl 1.4.2.3 </li>
170 <li>Use normal indenting for all arguments in a complex function call.
171 Do this:
172 <pre><code> callingMyFunction(<br> arg1,<br> arg2,<br> arg3);</code></pre>
173 Not this:
174 <pre><code> callingMyFunction(arg1,<br> arg2,<br> arg3);</code></pre>
175 Each argument should be placed on a separate line.
176 An exception is made for <code>PEG_TRACE</code> and
177 <code>PEG_TRACE_CSTRING</code> statements, where the first two
178 arguments should be placed on the opening line:
179 <pre><code> PEG_TRACE((TRC_HTTP, Tracer::LEVEL3,<br> "Connection IP address = %s",<br> (const char*)_ipAddress.getCString()));</code></pre>
180 </li>
181 <li>For an <code>if</code>, <code>while</code>, or <code>for</code>
182 condition that does not fit on a single line, indent peer subconditions
183 according to their level of nesting and indent other continuation lines
184 using normal indenting. Do this:
185 <pre><code> if ((variable1 == variable2) ||<br> ((anotherVariableToConsider ==<br> variable1 + variable2) &&<br> (dayOfWeek == "Tuesday")))</code></pre>
186 Not this:
187 <pre><code> if ((variable1 == variable2) ||<br> ((anotherVariableToConsider ==<br> variable1 + variable2) &&<br> (dayOfWeek == "Tuesday")))</code></pre>
188 </li>
189 <li>For a statement that does not fit on a single line,
190 karl 1.4.2.3 all continuation lines should be indented once from the first line.
191 For example:
192 <pre><code> sum = a + b + c +<br> d + e + f +<br> g + h;</code></pre>
193 </li>
194 <li>Do not separate a return type onto its own line. Avoid this:
195 <pre><code> int<br> f()<br> {<br> }</code></pre>
196 </li>
197 <li>Avoid use of "<code>(void)</code>" for an empty parameter list.
198 Use "<code>()</code>" instead.
199 </li>
200 <li>Avoid adding a space between function/method name the opening parenthesis.
201 Do this:
202 <pre><code> void f(int i);<br> f(10);</code></pre>
203 Not this:
204 <pre><code> void f (int i);<br> f (10);</code></pre>
205 </li>
206 <li>Include a space between a keyword and an opening parenthesis.
207 Do this:
208 <pre><code> if (i > 0)<br> for (i = 0; i < 10; i++)</code></pre>
209 Not this:
210 <pre><code> if(i > 0)<br> for(i = 0; i < 10; i++)</code></pre>
211 karl 1.4.2.3 </li>
212 <li>Do not add spaces around a condition. Do this:
213 <pre><code> if (cond)<br> while (cond)</code></pre>
214 Not this:
215 <pre><code> if ( cond )<br> while ( cond )</code></pre>
216 </li>
217 <li>Do not add a space between a template name and its type. Do this:
218 <pre><code> Array<Uint8> myArray;</code></pre>
219 Not this:
220 <pre><code> Array <Uint8> myArray;</code></pre>
221 </li>
222 <li>Avoid aligning variable names in a declaration list. Do this:
223 <pre><code> int x;<br> float y;</code></pre>
224 Not this:
225 <pre><code> int x;<br> float y;</code></pre>
226 </li>
227 <li>Avoid indenting "<code>public:</code>",
228 "<code>protected:</code>", and
229 "<code>private:</code>". Do this:
230 <pre><code> class X<br> {<br> public:<br> int f();<br> ...<br> private:<br> int _g();<br> ...<br> };</code></pre>
231 </li>
232 karl 1.4.2.3 <li>The '<code>#</code>' indicating a preprocessing directive is placed
233 at the beginning of a line. Nested preprocessing directives are
234 indented with one space after the '<code>#</code>' for each level of
235 nesting. The <code>#ifndef</code> used for header file include protection
236 is not considered a level of nesting. For example:
237 <pre><code>#ifdef PEGASUS_HAS_SIGNALS<br># ifdef PEGASUS_OS_TYPE_WINDOWS<br># include <windows.h><br># else<br># include <unistd.h><br># endif<br>#endif</code></pre>
238 </li>
239 <li>In a <code>switch</code> statement, indent the <code>case</code>
240 statement from the <code>switch</code> and indent the case logic from
241 the <code>case</code> statement. For example:
242 <pre><code> switch(n)<br> {<br> case 0:<br> printf("Rock");<br> break;<br> case 1:<br> printf("Paper");<br> break;<br> case 2:<br> printf("Scissors");<br> break;<br> default:<br> printf("Error");<br> break;<br> }</code></pre></li>
243 <li>A <code>switch </code>construct for an enumerated type the
244 construct MUST contain either all of the possible cases or the
245 default statement but not both. We encourage including all of the
246 enumerated types since this provides a compile time check if the
247 enumerated type changes. Do not include the default statement if
248 all of the possible enumerated types are included in the <code>case</code>
249 statements. At least in gcc this is enforced in the standard build with
250 the -Werror=switch flag which generates an error statement when the <code>switch</code> has an index of enumerated type
251 and lacks a <code>case</code> for one or more of the named codes of that
252 enumeration.</li>
253 karl 1.4.2.3
254 <li>Do not put parentheses around the return value in a
255 <code>return</code> statement.
256 </li>
257 </ol>
258
259
260 <h3>Naming</h3>
261 <ol>
262
263 <li>For class/struct names, use mixed case with initial upper case and
264 no underscores: <code>ThisIsAClassName</code>.
265 </li>
266 <li>For public member/variable names, use mixed case with initial lower case
267 and no underscores: <code>thisIsAMemberName</code>.
268 </li>
269 <li>For public method/function names, use mixed case with initial lower case
270 and no underscores: <code>thisIsAMethodName()</code>.
271 </li>
272 <li>Prepend an underscore to private and protected member and method names:
273 <code>_thisIsAPrivateMemberName</code>,
274 karl 1.4.2.3 <code>_thisIsAPrivateMethodName()</code>.
275 </li>
276 <li>General constants and macro names should begin with <code>PEGASUS_</code>.
277 </li>
278 <li>Use this format for constant and macro names:
279 <code>PEGASUS_CONSTANT_NAME</code>.
280 </li>
281 <li>Files names should use mixed case with initial upper case and no
282 underscores: <code>ThisIsAFileName.cpp</code>.
283 </li>
284 <li>A file should have the same name (and case) as the class it contains.
285 </li>
286 <li>Environment variables must begin with <code>PEGASUS_</code> and have
287 this form: <code>PEGASUS_ENVIRONMENT_VARIABLE</code>.
288 This applies to environment variables that control the build and test
289 configuration as well as those (if any) used by Pegasus at run time by forcing an error if the
290 </li>
291 <li>Test executable names should begin with 'Test' (to distinguish them
292 from other executables) and should use mixed case with initial upper
293 case and no underscores. The name should clearly indicate the feature
294 being tested. For example: <code>TestFeature1</code>.
295 karl 1.4.2.3 </li>
296 </ol>
297
298
299 <h3>Style</h3>
300 <ol>
301 <li>In a header file, use angle brackets (with a fully qualified path)
302 rather than quotes when including a file. Do this:
303 <pre><code> #include <Pegasus/Common/Array.h></code></pre>
304 Not this:
305 <pre><code> #include "Array.h"</code></pre>
306 </li>
307 <li>Use "<code>0</code>" rather than "<code>NULL</code>"
308 as a null pointer value.
309 </li>
310 <li>Avoid <code>throw()</code> declarations. These may be used
311 only when a method must not (and will not) throw any exception not
312 specified in the throw clause. When a <code>throw()</code>
313 clause is needed, include it on the method declaration and definition.
314 </li>
315 <li>Use <code>const</code> declarations liberally,
316 karl 1.4.2.3 but not on "plain old data type" parameters.</li>
317 <li>Catch exceptions by const reference when feasible.</li>
318 <li>Avoid inlining of large functions.</li>
319 <li>Avoid committing binary files to CVS.</li>
320 <li>Resolve compile warnings.</li>
321 <li>Define variables as late as possible.
322 A single object initialization is more efficient than initialization
323 followed by assignment. For example, this logic involves just a single
324 String construction:
325 <pre><code> String s = foo();</code></pre>
326 while this logic causes two String constructions and an assignment:
327 <pre><code> String s;<br> ...<br> s = foo();</code></pre>
328 </li>
329 <li>Present resources as part of classes, do not use them directly.</li>
330 <li>Use <code>new</code> and <code>delete</code> to manage dynamic
331 memory, not <code>malloc</code>, <code>free</code>, or
332 <code>strdup</code>.</li>
333 <li>When rethrowing an exception from a <code>catch</code>
334 block, avoid specifying the object to throw so that exception subtype
335 information is not lost and construction of an extra exception
336 object is avoided. Do this:
337 karl 1.4.2.3 <pre><code> catch (Exception&)<br> {<br> ...<br> throw;<br> }</code></pre>
338 Not this:
339 <pre><code> catch (Exception& e)<br> {<br> ...<br> throw e;<br> }</code></pre></li>
340 <li>Do not check whether a pointer is non-null before
341 deleting it. The check is unnecessary, since it is also performed by
342 the <code>delete</code> operator. Do this:
343 <pre><code> delete ptr;</code></pre>
344 Not this:
345 <pre><code> if (ptr)<br> {<br> delete ptr;<br> }</code></pre></li>
346 <li>Avoid using the compiler default implementations for
347 default constructors, copy constructors, and assignment operators.
348 These should be declared as private and left unimplemented if they
349 are not intended to be used. A decision to use a compiler default
350 should be documented with a comment in the class declaration.</li>
351 <li>Avoid the use of optional parameters in methods which
352 have interface compatibility requirements.</li>
353 <li>Avoid reading variables from the environment in
354 production (not debug or test) runtime code.</li>
355 <li>Definitions for the external interface declarations should not appear
356 in the external interface header files. Implementation logic for the
357 external interfaces should be contained in the associated source files.
358 karl 1.4.2.3 </li>
359 <li>Pass object parameters by reference, when feasible,
360 to avoid unnecessary copy constructions. For example, this:
361 <pre><code> void func(const String& s);</code></pre>
362 is preferred to this:
363 <pre><code> void func(String s);</code></pre></li>
364 <li>Avoid using the C++ standard template library (STL) and the standard
365 <code>string</code> class. (These tend to produce bloat and may have
366 portability issues.) These files should not be included:
367 <code><string></code>,
368 <code><vector></code>,
369 <code><map></code>,
370 <code><mmap></code>,
371 <code><set></code>,
372 <code><mset></code>,
373 <code><stack></code>,
374 <code><queue></code>,
375 and other STL header files.</li>
376 <li>Do not call <code>assert()</code> directly. Instead, use
377 <code>PEGASUS_ASSERT()</code> in production code and
378 <code>PEGASUS_TEST_ASSERT()</code> in test programs.</li>
379 karl 1.4.2.3 <li>Do not explicitly initialize Pegasus Strings to
380 <code>String::EMPTY</code>. This is the default value.</li>
381 <li>Do not add a null terminator to Pegasus Buffer strings.
382 <code>Buffer::getData()</code> ensures the resulting string is
383 null-terminated.</li>
384 </ol>
385
386 <h3>Documentation</h3>
387 <ol>
388 <li>Class members and methods should be documented with DOC++ comments.</li>
389 <li>Use <code>/** */</code> rather than <code>///</code> for DOC++
390 comments.
391 </li>
392 <li>Use this comment style for DOC++ comments:
393 <pre><code> class X<br> {<br> public:<br><br> /**<br> Creates widgets.<br> @param numWidgets The number of widgets to create.<br> @return true if successful, false otherwise.<br> */<br> Boolean createWidgets(Uint32 numWidgets);<br> };</code></pre>
394 </li>
395 <li>A description should end with a period, even if it is brief:
396 <pre><code> /**<br> Does something useful.<br> */</code></pre>
397 </li>
398 <li>Add a blank line between documented methods:
399 <pre><code> /**<br> Does something quite useful.<br> */<br> void f();<br><br> /**<br> The previous method has a newline after it<br> to improve its visibility.<br> */<br> void g();</code></pre>
400 karl 1.4.2.3 </li>
401 </ol>
402
403 <h3>Portability Considerations</h3>
404 <ol>
405 <li>The use of platform specific <code>#ifdef</code>'s should be minimized
406 and discouraged. It is preferred to abstract the mechanics of
407 dissimilar platforms in separate modules (such as DirPOSIX.cpp vs.
408 DirWindows.cpp) or by using abstraction functions or macros such as
409 those that appear below.</li>
410 <li>In header files, identifiers from the standard library (such as
411 <code>ostream</code>, <code>istream</code>, <code>cout</code>, and
412 <code>cerr</code>) must be enclosed in a <code>PEGASUS_STD()</code>
413 macro (which prepends <code>std::</code> to the argument on some
414 platforms).
415 </li>
416 <li>Do not use the <code>PEGASUS_STD()</code> macro in a source file.
417 Instead, specify <code>PEGASUS_USING_STD;</code> at the beginning of
418 the file.
419 </li>
420 <li>Do not use <code>PEGASUS_USING_STD;</code> or
421 karl 1.4.2.3 <code>PEGASUS_USING_PEGASUS;</code> in a header file.
422 </li>
423 <li>Avoid use of conditional compilation for obscuring platform
424 differences. Use platform abstractions in the appropriate platform
425 files or in the System*.cpp files in Common.
426 </li>
427 <li>Windows requires symbols to be explicitly imported/exported from
428 dynamic libraries. Linkage.h files are used to define the necessary
429 linkage macros. Each dynamic library that exports symbols should
430 define a <code>PEGASUS_<LIBRARY>_LINKAGE</code> symbol in a
431 Linkage.h file. Each symbol that is exported from the library
432 must be declared with this linkage macro. For example:
433 <pre><code> class PEGASUS_COMMON_LINKAGE String;<br><br> PEGASUS_COMMON_LINKAGE void globalFunction();</code></pre>
434 </li>
435 <li>A <code>main()</code> function must return an int (required by
436 Windows NT).
437 </li>
438 <li>Do not use <code>ultostr()</code>; use <code>sprintf()</code>
439 instead.
440 </li>
441 <li>Do not declare a throw clause without parentheses:
442 karl 1.4.2.3 <pre><code> void f() throw TooBad;</code></pre>
443 </li>
444 <li>Do not include a definition of a static member with its declaration:
445 <pre><code> class X<br> {<br> public:<br><br> static const Uint32 COLOR = 225;<br> };</code></pre>
446 Use this instead:
447 <pre><code> class X<br> {<br> public:<br><br> static const Uint32 COLOR;<br> };</code></pre>
448 And add the definition in the source file:
449 <pre><code> const Uint32 X::COLOR = 225;</code></pre>
450 </li>
451 <li>Use <code>PEGASUS_64BIT_CONVERSION_WIDTH</code> for
452 printf and scanf conversions of 64-bit integers rather than
453 <code>ll</code> or <code>L</code>.
454 Do this:
455 <pre><code> Sint64 i64 = 10;<br> printf("i64 value = %" PEGASUS_64BIT_CONVERSION_WIDTH "d.\n", i64);</code></pre>
456 Instead of this:
457 <pre><code> Sint64 i64 = 10;<br> printf("i64 value = %lld.\n", i64);</code></pre>
458 </li>
459 <li>Do not include class scoping on methods or members in a class definition.
460 Do this:
461 <pre><code> class X<br> {<br> public:<br><br> int myMethod();<br> };</code></pre>
462 Not this:
463 karl 1.4.2.3 <pre><code> class X<br> {<br> public:<br><br> int X::myMethod();<br> };</code></pre>
464 </li>
465 <li>Do not use <code>Pegasus::</code> to scope symbols. Not all platforms
466 support C++ namespaces, and this will cause a compilation failure. If
467 a symbol must be explicitly scoped to the Pegasus namespace, use the
468 <code>PEGASUS_NAMESPACE()</code> macro instead.</li>
469 <li>Use consistent declarations of <code>const</code> parameters in method
470 declarations and definitions.</li>
471 </ol>
472
473 <h3>Avoiding Unused parameter, variables, values, functions ...</h3>
474 <p>In general, avoid unused variables, parameters, values and
475 functions. Many compiler come with support to automatically detect
476 these, use them. The OpenPegasus build using gcc will flag unused variables
477 as errors.
478 The Pegasus Architecture team may completely disallow checkin of code that
479 generates unused* warnings to CVS in the future.<br>
480 </p>
481 <ol>
482 <li>Avoid unused parameter warnings. In case the function
483 signature cannot be changed since the function codes an
484 karl 1.4.2.3 interface, leave the parameter name off in the function
485 definition while keeping the parameter type in place. In the
486 following example of function <i>main()</i> the parameter <i>argv</i>
487 is used later on but parameter <i>argc</i> is not. Do this:<br>
488 <pre><code>int main(int, void** argv)<br>{<br>}</code></pre>
489 Not this:<br>
490 <pre><code>int main(int argc, void** argv)<br>{<br>}</code></pre>
491 </li>
492 <li>Avoid unused variables when the return value of a function is
493 assigned to a variable only to be used to do an assert check
494 with PEGASUS_ASSERT by instead using macro
495 PEGASUS_FCT_EXECUTE_AND_ASSERT. It helps avoid such unused
496 variables when PEGASUS_NOASSERTS is enabled (assertion
497 disabled). PEGASUS_FCT_EXECUTE_AND_ASSERT compares the return
498 value of function against VALUE for equalness but only if
499 asserts are enabled. The Function FCT will always be called
500 (equal if asserts enabled or disabled). Do this:
501 <pre><code>PEGASUS_FCT_EXECUTE_AND_ASSERT(true, f());<br> </code></pre>
502 Not this:
503 <pre><code>bool returnCode = f();<br>PEGASUS_ASSERT(true == returnCode);<br> </code></pre>
504 </li>
505 karl 1.4.2.3
506 </ol>
507
508
509 <h2><font color="#000000">Discussion</font></h2>
510 <p>Suggestions for additional conventions are listed here for discussion:
511 </p><ul>
512 <li>Handling of error conditions (cerr vs. logging) and exceptions</li>
513 <li>Testing (perhaps reference another document)</li>
514 <li>Is it appropriate to make a statement about defining
515 localizable messages in the appropriate message bundle?
516 </li>
517 </ul>
518 <p></p>
519
520
521 <hr>
522 <p><i><font size="2">Copyright (c) 2005 EMC Corporation; Hewlett-Packard
523 Development Company, L.P.; IBM Corp.; The Open Group;
524 VERITAS Software Corporation</font><br>
525 <br>
526 karl 1.4.2.3 <font size="1">Permission is hereby granted, free of charge, to any person
527 obtaining a copy of this software and associated documentation files
528 (the "Software"), to deal in the Software without restriction,
529 including without limitation the rights to use, copy, modify, merge, publish,
530 distribute, sublicense, and/or sell copies of the Software, and to permit
531 persons to whom the Software is furnished to do so, subject to the following
532 conditions:</font><br>
533 <font size="2"><br>
534 </font>
535 <font size="1">THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE SHALL BE
536 INCLUDED IN ALL COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE SOFTWARE IS
537 PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
538 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
539 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
540 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
541 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
542 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
543 SOFTWARE.</font></i></p>
544 <hr>
545 <p>Template last modified: <b>March 9th 2004</b> by <b>Martin Kirk<br>
546 </b>Template version: <b>1.8</b></p>
547 karl 1.4.2.3
548 </body></html>
|
Return to
CodingGuidelines.htm
CVS log
Up to [Pegasus] / pegasus / doc