C++ Coding Standards

Revised: January 2017

There are three kinds of coding standards: obligatory, advisory and aesthetic. The obligatory coding standards exist to ensure that your program can be compiled, executed and graded. Naturally, if your program does not compile, does not run or is unreadable by a human being, there will be major deductions from your grade. Obligatory standards also exist to ban some very bad programming practices. The advisory coding standards are "good for you". They help you maintain your code and avoid nasty bugs. If you do not follow advisory coding standards and run into nasty bugs, then it is your own fault that your program is late or does not work. The aesthetic coding standards keep your code pretty. These are the most controversial since reasonable people will disagree on what is pretty. However, since there is much agreement on what is ugly, you may lose points on your project if your code is ugly, because no one wants to stare at ugly code all day long.

It is your responsibility to understand these standards. If you have any questions, ask your instructor or any of the TAs.

General

(Obligatory) Your programs must compile on GL with g++ without using any optional compiler flags. Do not use C++11 or C++14 features in your programs.
(Obligatory) You must not use global variables, static class data members or non-static data members to simulate parameter passing or return values. Global constants are OK.
(Obligatory) Your program should not generate output to the console or to files unless required by the project description. (I.e., clean up all those printf and cout statements you used for debugging.)
(Obligatory) Your program should not ask for user input or read from a file unless required by the project description. If you add extraneous requests for input, this will break most grading scripts.
(Obligatory) File extensions: use .cpp for implementation files and .h for header files. No other extensions are permitted.

File Organization

(Obligatory) For every project, the main() function must be in a separate file, usually called driver.cpp. Do not include a main function in the same file as the implementation of your member functions.
(Advisory) Each class must be defined in a separate header file. Name each file after the class it contains and give it a .h file extension. For example, if you have a class that represents cars, the class should be named Car and the header file should be Car.h
(Advisory) Member functions should be implemented in a separate .cpp file. For example, if you have the Car class, the member functions for that class should be in a file should be named Car.cpp. Sometimes short implementations for member functions can be placed with the class definition in header files (e.g., getters and setters).
(Obligatory) Every header file must be guarded using compiler directives such as: where HEADERFILE_H is replaced with the name of your header file. These directives prevent multiple inclusions of the header file (a bad thing).
(Obligatory) A header file for a class must itself include all header files necessary for a program to use the class. For example, a program that uses your Car class must be able to use all the features of the Car class simply by Programs should not be required to include any other header files to be compiled with the Car.
(Advisory) Remove unnecessary #include directives from your code. It slows down compilation and shows that you don't understand which header files are needed.

Documentation and Formatting

(Obligatory) Your code must be readable by human beings.
(Obligatory) Your code must be well-documented.
(Obligatory) Your code must have meaningful class, function and variable names.
(Advisory) You should be able to determine whether an identifier is a function, a class or a variable from its name. One scheme is to capitalize class names, use verbs for functions and nouns for variables.
(Advisory) You should be able to determine whether a variable is a data member or an local variable from its name. One scheme is to prefix every data member with m_.
(Advisory) You should be able to determine whether a variable is a pointer from its name. One scheme is to append ptr at the end of every pointer.
(Aesthetic) MultiWord identifiers should be camelCased.
(Aesthetic) Use an underscore character between words of a multi_word_identifier.
(Aesthetic) Use a consistent naming scheme, except when you don't want to.
(Obligatory) You must use a consistent indentation scheme where the level of a code block's nesting can be inferred from the level of indentation.
(Advisory) You should not use tabs because the tab character is expanded differently by different editors and shells and depend on people's personal settings. Your indentation scheme must be correct when displayed in all situations.
(Aesthetic) Indent 3 or 4 spaces.
(Aesthetic) Keep lines under 80 characters. Long lines get wrapped and are difficult to read.
(Aesthetic) Use blank lines to separate pieces of code for readability.
(Aesthetic) Use only one private, protected and public section in a class definition. The public section comes first, followed by protected and then private.
(Advisory) Every data member of a class should be private.
(Aesthetic) All functions (member functions and stand-alone functions) should have complete comments (description, pre/post conditions) in the header file above the function prototype. While fewer comments are required in the .cpp file, this may be where you have the most since it will have more detail.
(Advisory) Member functions should be const whenever possible.
(Advisory) Use constants instead of magic numbers.
(Aesthetic) Use spaces around all operators. For example, write instead of
(Aesthetic) Use a consistent style for braces.
(Advisory) Use braces for single statement in if/else/while/for structures. For example:

CMSC 341 Data Structures — All Sections — Fall 2017

C++ Coding Standards

Revised: January 2017

General

File Organization

Documentation and Formatting