# C++ Coding Standards

### Revised: October 2019

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.

• (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 should 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 or 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 or car.cpp. Sometimes short implementations for member functions can be placed with the class definition in header files (e.g., getters and setters).

• (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 #include "Car.h" Programs should not be required to include any other header files to be compiled with the Car class.

• (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 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 a local variable from its name. One scheme is to prefix every data member with _ or 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.

• (Aesthetic) Use spaces around all operators. For example, write x = y + 5; instead of x=y+5;

• (Aesthetic) Use a consistent style for braces.

• (Advisory) Use braces for single statement in if/else/while/for structures. For example: 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; }