Code Documentation Plan (Page 1)

<<Back 1 2 3 Next>>

Coding Standards are important for many reasons. First, if there is some set of standards, all developers will feel as if they are on the same level. The standard for this project was developed using the wide and varied experience of the RAFS team and also by the international development community as a whole. These standards were developed with the following goals in mind:

• Developers can look at any code and surmise what is going on.
• Developers new to the code can get up to speed quickly.
• Developers new to the API need not develop their own coding style.
• Developers new to the API will not make the same mistakes over and over again as previous development teams have.
• Programmers make fewer mistakes in a consistent environment.

This section of the Design Document is our coding standard for writing C++ code to use with the Saphira 8.1 API for the ActivMedia robot. The range of this section is devoted to coding style, not to code function.

Background

The various experiences of our team, both in and out of the classroom and industry, have developed this standard in an attempt to make this latest project progress smoothly. Are these standards necessary or vital to the fruition of the project? Probably not, but they are meant to help and as developers we will graciously accept help when provided to us. When a standard is composed in a logical matter using reasonable assessments it can also be overbearing or technically lacking. Keep in mind that this project is a team effort, therefore it was easier to develop this standard as a team.

Introduction

This section of the document does not address functional organization. While we have tried to be clear, concise, and complete as possible, this standard cannot be imposed on all situations or circumstances.

The standards listed in this section of the document pertain to this project only. However, we welcome, invite, and encourage other organization to use our coding standard for their software development projects. We do ask though that notification of the members of the RAFS group and the Southern Illinois University Edwardsville School of Engineering of their intentions to use this section of the design document.

Standards Enforcement

The RAFS team members are great believers in the “Honor System”. There is no committee on enforcement of the coding standard, only peer reviews of one another’s code and the help of other teammates in debugging code modules. This coding system is encouraged for the latter of these two reasons.

Names

Since names are the heart and soul of development, names that are clear, unique, and descriptive are of great value to the development team and to future generations of developers who will be upgrading, updating, and studying our code.

Class Names

Names of classes should be names of things that already exist (both in the computer system and the real world). If we are writing a class to describe desks, we should name the class “Desk”. If we are writing a class for error we should name the class “Error”. Compound words and names containing more than three words will be avoided at all costs.

Source Code File Naming Conventions
First, as with most computer files, files require a name, dot separator, and suffix.
· All Source code files will end with a “cpp” or “c” suffix
· All Header files will end with an “h” suffix
· All files will use a dot separator between name and suffix “*.h” or “*.cpp”

<<Back 1 2 3 Next>>