Return to
PegasusProgrammingGuidelines.htm
CVS log
Up to [Pegasus] / pegasus / doc / WorkPapers
|
Return to
PegasusProgrammingGuidelines.htm
CVS log
|
Up to [Pegasus] / pegasus / doc / WorkPapers
|
|
File: [Pegasus] / pegasus / doc / WorkPapers / PegasusProgrammingGuidelines.htm
(download)
/
(as text)
Revision: 1.1.2.1, Wed Jul 25 15:33:15 2001 UTC (22 years, 10 months ago) by karl Branch: dev Changes since 1.1: +33 -17 lines corrections |
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Pegasus Project Working Paper</title>
</head>
<body>
<H1 align="center">Pegasus Project Working Paper</H1>
<H1 align="center">Programming Guidelines For the Pegasus Project</H1>
<b>AUTHORS:</b> M. Brasher, K. Schopmeyer
<p><font size="1">Last Update <!--webbot bot="Timestamp"
S-Type="EDITED" S-Format="%A, %B %d, %Y %I:%M %p" startspan -->Tuesday, July 24, 2001 08:48 PM<!--webbot bot="Timestamp" i-CheckSum="54098" endspan -->
</font></p>
<p>Revision Status</p>
<table border="1" width="80%">
<tr>
<td width="25%">Revision</td>
<td width="25%">Date</td>
<td width="25%">Author(s)</td>
<td width="25%">Reason</td>
</tr>
<tr>
<td width="25%">0.1</td>
<td width="25%">5 July 2001</td>
<td width="25%">M. brasher, K. Schopmeyer</td>
<td width="25%">first Draft</td>
</tr>
<tr>
<td width="25%">0.2</td>
<td width="25%">24 July 2001</td>
<td width="25%">M. Brasher, K. Schopmeyer</td>
<td width="25%"> </td>
</tr>
<tr>
<td width="25%"> </td>
<td width="25%"> </td>
<td width="25%"> </td>
<td width="25%"> </td>
</tr>
<tr>
<td width="25%"> </td>
<td width="25%"> </td>
<td width="25%"> </td>
<td width="25%"> </td>
</tr>
</table>
<h2>Introduction</h2>
<p>This document defines the basic set of guides and rules for programmers
contributing to the Pegasus Project</p>
<p>NOTE: This is a draft copy for comment.</p>
<p>RULES and Suggestions - A number of the guidelines below are absolute rules
that we must follow in the Pegasus project. These are the things that will
help insure portability and effective interoperability of the components.</p>
<p>Other area are "suggestions" that we strongly suggest be followed
so that 1) the code will be readable and usable, 2) we develop a single look to
our source code, etc. In some cases, there may be reasons to bypass some
of these suggestiions but we strongly encourage everybody to follow them.
In fact, if there is a real reason we will change to what the group wants and
suggestions.</p>
<h2>Coding Conventions</h2>
<OL>
<LI><b>Indenting Code</b> - Indent by increments of 4 characters (with tabsize of
8). Use the TAB character. This is the accepted norm for open source
code.
<LI><b>Naming Conventions</b> - <font face="Courier New"> ThisIsAClassName</font> - no underscores.
<font face="Courier New">
thisIsAMethodName()</font> - no underscores.
Files Names should take advantage of case and avoid underscores.
Files should have the same name as the class (and same case).
<br>Prepend '_' to private members (including methods).
<LI><b>Code Line Length</b> - Lines should not span more than 80 columns.
When methods span more than 80 columns, do this:
<pre>
void MyClass::myMethod(
const char* someReallyLongName,
const char* someOtherReallyLongName);
</pre>
<LI> Use "char* x" rather than "char *x". Either is normally legal for the
majority of compilers.
<LI><b>Use of <font face="Courier New">const</font></b>. Use <font face="Courier New"> const</font> whenever possible.
Use <font face="Courier New"> const</font> methods whenever possible.
<LI><b>Braces</b> - Put opening brace on a line by itself. Braces must be aligned with control keyword:
<pre>
for(...)
{
....
}
</pre>
Not this:
<pre> for (...)
{
....
}</pre>
or this:<pre> for (...){
....
}</pre>
<LI><b>Using Space</b> - No spaces after names.
<br>Separate functions with blank lines.
<pre> class X
{
public:
void f();
void g();
};</pre>
<p>
<LI> Not "void f ()" but "void f()".
<LI>Avoid this:<br>
<font face="Courier New">
callingMyFunction(blah,<br>
blah2,<br>
blah3);</font><br>
Do this:<br>
<font face="Courier New">callingMyFunction(<br>
blah,<br>
blah2,<br>
blah3);</font>>/pre><br>
<LI>
<pre>Avoid this:
int x;
float y;
</pre>
<LI>Use 0 and not NULL.
<li>Don't separate return type onto its own line:
Avoid this:
<pre>
int
f()
{
....
}
</pre>
<li><b>Comments</b> - Use /** */ rather than /// for DOC++.
<li><b>Conditional Compilation </b>- Avoid use of conditional compilation for obscuring platrform
differences. Use (or put) routines in appropriate platform files
or in the System*.cpp files in Common.
</ol>
<h2>Testing</h2>
<p>Effective testing is essential to allowing a group to work together in a
common code environment. We have created a structure where unit and even system
level tests can be created and committed to the source tree as part of all
development. Each major directory section includes a tests subdirectory
with individual directories for tests. Please create and commit tests as part of
the normal environment wherever it is possible. All core code should include
tests created in this manner as well</p>
<p>If you change code to extend it or make corrections, please review the
corresponding tests code to 1) add tests to cover the problem corrected 2)
extend tests to cover the new code added.</p>
<p>Be mindful that the tests must run on all supported platforms and
that a commit may break another platform.</p>
<p>Tests must clean up the effect they have on the repository.</p>
Changes must work on all platforms. Commits must not break any
platform.
Always write a regression test for everything.
<p>No warnings should be committed.
Test big changes on at least Windows and Unix (or Linux)
<h2>Committing Code to CVS</h2>
<p>Don't commit anything that breaks the build (try a clean slate
checkout and build). Remember that if the build is broken for you, it
is also broken for everybody that gets the new code.</p>
<p>Always build and run all regression tests before committing. </p>
<p>No binaries may be committed to repository. </p>
<p> There are a few exceptions to this rule but binary files cause problems</p>
<h2>Using Outside Code and Libraries</h2>
<p>This is an opensource project. All code that is contributed to this
project must be open source and must be made available under the standard
license used by the Pegasus project. Do not use any outside libraries that do
not meet this criteria. Further, every reference to outside code make it
more complex for others to build and work with the project and introduces
potential portability problems. At the same time, there may be real
reasons to use outside code and libraries at times. Thus, for example, the
initial project used the ACE_wrappers libraries extensively but with the
objective of eventually providing a replacement. That replacement has been
produced, partly because ACE was not available on all of the platforms</p>
<h2>Using Make</h2>
<p>The Pegasus project has developed a consistent and portable make system that
allows bot localized and global builds on a wide variety of systems from Windows
to Unix to the tandem platforms today. This is based on 1) using the GNU
Make tool as the core of the make system, 2) minimining the use of other tools.
</p>
<p><<EXPLAIN THE MAKE SYSTEM OR REFERENCE DOC>>>
</p>
<p>All code must be reachable (built) from master makefile. Otherwise it will not be reached when doing mass substitutions, testings of
builds, and license changes.
</p>
<h2>DOCUMENTING
</h2>
<p><<<THIS SECTION NEED TO BE COMPLETED>>>
</p>
<h2>Portability Issues</h2>
<p>TBD</p>
<h2>The Source Tree Structure</h2>
<p>We work from a single source tree in CVS. We have a fixed structure for
this structure.</p>
<p><<<THIS SECTION IS TBD>>></p>
<p> </p>
<p> </p>
<p>---END OF DOCUMENT--</p>
</body>
</html>
| No CVS admin address has been configured |
Powered by ViewCVS 0.9.2 |