The team is working on an existing code developed by N.O.R.R.T (Network Operated Robotics Research Team) and so will comply with the same coding standards. The following document is the N.O.R.R.T documentation for coding standards. This document is subject to change as Team evolution may not be able to follow the same standards, in which case the new standards will be documented appropriately.
1. Introduction
In order to promote readability, clarity and maintainability of our code this document lists practices, standards and style guidelines for all NORRT programs. NORRT will be using three languages to implement its system. Accordingly this document will be broken into three parts containing standards for C++, Java, and HTML.
• Languages
• C++
2.1.1. Variable Names
All variables should be named in Hungarian notation (see appendix a)
Use capital letters in favor of underscores in midst of variable names (e.g. iUserCount instead of i_user_count)
2.1.2. File Names
Header files that define classes should be named the class name “.h”
2.1.3. Class Names
Reference types should end in “Ptr”
The first letter of a class name should be capitalized and the names of its members and methods should begin with a lowercase letter.
2.1.4. Includes
(a) Includes are listed after their dependencies
(b) Header files should begin with an “#ifndef” followed by “NORRT_FILENAME_H”
2.1.5. Brackets
(a) Opening bracket will always appear on its own line
(b) The closing bracket will be aligned below the opening bracket.
(c) Code between brackets will be tabbed one column to the right of the bracket's column
2.1.6. Tabs
Tabs will be equivalent in length to four spaces but will be represented by the tab character.
2.1.7. Parenthesis
(a) No spacing between a function name and its open parenthesis.
(b) No spacing after an if, while, for, or switch statement and before the opening parenthesis.
2.1.8 Commenting
Every function will be preceded by a comment block which will list the purpose of that function and its input and output parameters and describe any side effects that it may have.
2.1.9. Declarations
(a) Declarations should have their variable names aligned with each other.
(b) Initial values for these variables should have their equal signs aligned with each other.
2.1.10. Globals
2.1.10.1. Variables
(a) Should be avoided.
(b) If global data communication is necessary it should be done through singleton classes.
2.1.10.2. Constants
(a) Constants should be defined by means of constant variables as opposed to using the “#define” complier directive.
(b) Constants should be in all caps and should use underscores for word separation.
2.1.11. Long Functions Parameter Lists
Function calls and declarations with five or more parameters should have one parameter per line and aligned.
2.1.12. Pass by Reference
(a) Output parameters should be passed by reference as opposed to pointers passed by value.
(b) An exception to the above stated rule is made when interfacing with an API in which pointer passing is required.
2.1.13. Class Locations
Classes should be defined in header files one class per file.
2.1.14. Non-Class Data Structures
Structs will not have methods to preserve data integrity unions will be avoided.
2.2. Java
Java standards will follow the C++ guidelines listed above where applicable.
2.2.1. Import Statements
Do not import both a specific member of a package and the entire package.
2.2.2. Class Locations
(a) Public classes should appear in there own file.
(b) Private classes may appear in the same file as a public class.
2.3. HTML
2.3.1. Tabbing
If a tag contains tags then its close should be on a new line aligned with its open. The included tags should be tabbed on column to the right of open and close.
2.3.2. Alternate Text
Alternate text should appear on all graphical items.
2.3.3. Java Script
Java script uses the formatting guidelines specified for C++.
2.3.4. Comments
Comment parameters on applet and embed tags.
About Us |Contact Us | ©2004 Team Evolution