CMSC 202 - General C++ Coding Standards

Part of every project grade is based upon how well these standards are followed.

C++ File Extensions

File Naming

For most projects, you will be creating your own classes. In these projects, the following standards also apply.

• All classes are defined in a separate header file. Name each file after the class it contains and give it a .h file extension.
• All classes are implemented in a separate source code file. Name each file after the class and give it a .cpp file extension.
• No member function is to be implemented in a class header file (i.e., no inline methods are permitted. All implementation belongs in the matching implementation file.)

File Organization

• Every header file must be guarded using the

    #ifndef FOO_H
    #define FOO_H
          .
          .
    #endif
  

  style. This style is used to avoid multiple inclusions of the header file.

• A header file is to be included in a given file if and only if the header defines an entity referred to in the given file. For example, suppose the header file Foo.h refers to an ifstream entity and a string entity. Then, definitely do include fstream and string in the Foo.h. Now, suppose the implementation file Foo.cpp refers to an ifstream entity, but not a string entity. Then Foo.cpp should include Foo.h and fstream, but not string. Note that fstream is included even though its inclusion is also caused by including Foo.h. Guarded header files keep this from causing a multiple definition error and your code becomes cleaner and more readable.

• The executable for a project must be named after the project. For example, the executable for project 3 must be named Proj3 (notice the capital "P"). This is very important because the graders will look for that file to run your program. The graders will not run a.out or any other executable. The executable name is controlled by your makefile - get it right.

Class Definition Standards

• All class names begin with uppercase. Multi-word class names follow variable/function naming convention below.
• Only one private, protected and public section in a class definition. public comes first, followed by protected and then private.
• Every data member of a class must be private.
• You may use global symbolic constants (const), but not global variables.
• Class methods follow function naming conventions below.
• Class methods must have complete function header comments in the header file. Fewer comments are required in the .cpp file.
• Class methods must be const whenever possible.
• Class data members begin with m_ and follow the variable naming conventions below. Example: int m_length; int m_nrStudents;

Variable, Constant and Function Declarations

• Use meaningful descriptive variable names!!
  For example, if your program needs a variable to represent the radius of a circle, call it 'radius', NOT 'r' and NOT 'rad'.
• Begin variable names with lowercase letters
• The use of single letter variables is forbidden, except as simple 'for' loop indices, temporary pointer variables and in special cases such as x- and y-coordinates.
• The use of obvious, common, meaningful abbreviations is permitted. For example, 'number' can be abbreviated as 'num' as in 'numStudents' or as 'nr' in 'nrStudents'.
• If commented, variables must be declared one per line. Comments should appear on the same line without wrapping (use two lines if necessary).
• Do not use global variables
• Separate "words" within variable names with mixed upper and lowercase. (e.g. grandTotal)

• Begin function names with uppercase letters.
• Use active function names, generally beginning with a verb and including a noun -- GetName( ).
• Function prototypes must include parameter names as well as types.
• Functions with no parameters must include a void (not empty) parameter list.
  i.e. int MyFunction( ); is NOT acceptable and should be declared as
  int MyFunction( void );
• Default values for parameters must be specified in the prototype.
• Parameters must be passed by reference whenever appropriate.
• Reference parameters must be const whenever appropriate.
• Separate "words" within function names with mixed upper and lowercase. (e.g. ProcessError)

• Constants should be commented on the same line on which they occur. Such comments should not wrap; use two lines if necessary. const int NUM_STUDENTS = 35; // number of students in the class const int NUM_SECTIONS = 4; // number of sections of CMSC 104 const float CUTOFF = 88.5; // cutoff for an "A" for the 2001 // spring semester
• Constants should be used for magic numbers and strings whenever possible. Points will be deducted from projects with code such as int arrary[30]; for (int i = 0; i < 30; i++) array[i] = -3; if (command == "ADD") // do something else if (command == "MULTIPLY") // do something else

Documentation

Use of Whitespace

The prudent use of whitespace (blank lines as well as spaces) goes a long way to making your program readable.

• Use blank lines to separate pieces of code for readability to separate unrelated sections of code and thereby group logically related lines of code together.
  This code fragment is unreadable and results in deductions // count total number of students for (int i = 0; i < size; i++) totalStudents += class[i]; cout << "total students = " << total students << endl; while (moreStudents == true) { // read student last name ReadStudentName(); // print full name PrintStudentName(); // now verify student info goodInfo = VerifyStudentInfo(student); if (goodInfo == true) cout << "good info" << endl; } cout << " this is the end" << endl; and should be formatted like this // count total number of students for (int i = 0; i < size; i++) totalStudents += class[i]; cout << "total students = " << total students << endl; while (moreStudents == true) { // read student last name ReadStudentName(); // print full name PrintStudentName(); // now verify student info goodInfo = VerifyStudentInfo(student); if (goodInfo == true) cout << "good info" << endl; } cout << " this is the end" << endl;
• DO NOT use tabs (unless your text editor changes tabs to 3 or 4 spaces). Tabs may be interpreted differently by different editors.
• Use 3 or 4 spaces (not 6 or 8) for each level of indentation. and be consistent. Too much indenting makes the code unreadable and hastens line wrapping. // This is an example of good formatting if ( x > 90 ) { statement 1; statement 2; } else { statement 3; } // This is an example of too much indenting if ( x > 90 ) { statement 1; statement 2; } else { statement 3; } // This is an example of inconsistent indenting if ( x > 90 ) { statement 1; statement 2; } else { statement 3; }
• Use spaces around all operators. For example, write x = y + 5; NOT x=y+5;
• Using the emacs or xemacs editor along with the .emacs file provided for you will automatically indent your code appropriately. The pico editor will not do so.

Use of Braces

• Use a consistent style for braces. See the indentation styles for appropriate placement of braces.
• Braces are not required for single statement if/else/while/for structures, assuming suitable indentation is used to show the structure. For example, the following structures are permitted if (grade > 90) cout << "You got an A" << endl; else cout << "No A for you" << endl; for (i = 0; i < 30; i++) array[i] = -3;

Comments

Comments are the programmer's main source of documentation.

From "The Practice of Programming" by Brian Kernighan and Rob Pike, page 23

Comments are meant to help the reader of a program. They do not help by saying things that the code already plainly says, or by contradicting the code, or by distracting from the code with elaborate typographical displays. The best comments aid the understanding of a program by briefly pointing out salient details or by providing a larger-scale view of the proceedings".

File Header Comments

1. The file name
2. The project number
3. Your name
4. The date the file was created
5. Your section number
6. Your UMBC e-mail address
7. A description of what the code in the file does

Function Header Comments

1. The function's name
2. The function's pre-condition(s) (if there are no pre-conditions, say so).
3. The function's post-condition(s).

A post-condition is a statement describing what will be true when the function call is completed (assuming the pre-condition is met and the function completes). (see text page 113).

For example,

In-Line Comments

• In-line comments are used to clarify what your code does, NOT how it does it.
• An in-line comment MUST appear above the code to which it applies and is indented to the same level as the code.
  The following example is acceptable. // check every element of the array for (i = 0; i < ARRAYSIZE; i++) { // add one to odd values if (array[i] % 2 == 1) { array[i]++; } } The following example is not acceptable for (i = 0; i < ARRAYSIZE; i++) // check every element of the array { if (array[i] % 2 == 1) // add one to odd values { array[i]++; } }
• Be sure your comments don't contradict the code
• Don't comment bad code -- rewrite it
• Don't comment the obvious. Comments like these are worthless // return true return true; // increment counter ++counter;