**C++ Coding Standards and Guidelines**

**Peer Review Checklist**

Last Updated: 11/13/2023

  --------------- ------- ---------------- ---- ----------- ------------ ----- ----- ----------
  **Reviewer\'s                                             **Peer                    
  Name:**                                                   Review                   
                                                            Date:**                  

  **Project       ** **                                     **Project                 
  Name:**                                                   ID:**                    

                                                            Enter if                 
                                                            applicable               

  **Developer's                                 **Project                            
  Name:**                                       Lead:**                              

  **Review Files                                                                     
  & Source code**                                                                    

                                                                                     

                                                                                     

                                                                                     

  **Code                                                                             
  Approved**                                                                         
  --------------- ------- ---------------- ---- ----------- ------------ ----- ----- ----------

The following check list is to be used in the assessment of C++ source
code during a peer review. Items which represent the code being reviewed
should be checked.

#  General Programming Standards and Guidelines 

Refer to the OHD General Programming Standards and Guidelines Peer
Review\
Checklist to assess the adherence to the OHD General Programming
Standards and\
Guidelines.

#  C++ Programming Standards

## Readability and Maintainability

\_\_\_\_\_\_Consistent indentation (3 or 4 spaces)

\_\_\_\_\_\_Consistent use of braces

\_\_\_\_\_\_No tabs used

### File Names

\_\_\_\_\_\_Header files and namespace files use suffixes: .h, .H, .hh,
.hpp, or .hxx

\_\_\_\_\_\_Source files use suffixes: .C, .cc, .cpp, or .cxx

\_\_\_\_\_\_UpperMixedCase is used for class or namespace file names

\_\_\_\_\_\_lowerMixedCase is used for function file names

### File Organization

\_\_\_\_\_\_Each file contains only one class declaration or definition
except functors and

> static classes

\_\_\_\_\_\_File includes a brief description of the file after the
*documentation block*

\_\_\_\_\_\_The content of the file is in the following order:

1.  The preprocessor directives to prevent multiple inclusions in header
    files.

2.  The *Documentation block* described in the *\"OHD General Software
    Development Standards and Guidelines\"*

3.  A brief description of the file

4.  Include files

5.  #defines and Macros

6.  The 'use' directives in the source files but not in header files

7.  Class or function declaration or definition

### Include Files

\_\_\_\_\_\_C++ standard library headers that have no extension are used

\_\_\_\_\_\_New prefix c is used instead of the old extension .h for C
standard header files

\_\_\_\_\_\_The \< \> pair for library and system headers is used

\_\_\_\_\_\_The \" \" pair for non-system (user defined) headers is used

\_\_\_\_\_\_No absolute or relative paths to point to the header files
are used

\_\_\_\_\_\_The system header files first in alphabetical order followed
by the non system

> include files (including COTS includes) also in alphabetical order

### Comments

\_\_\_\_\_\_The JavaDoc convention format is used for the documentation
comment

\_\_\_\_\_\_The C++ comment \"//\" style or the C style (/\* \... \*/)
is used for inline comments

### Naming Schemes

\_\_\_\_\_\_namespace, class, struct, template argument, and parameter
names use

> uppercase letters as word separators with the first character
> capitalized

\_\_\_\_\_\_Macro and #defined constant, enum, union, class static data
member, and

> global variable names are all capitalized with underscore as
> separators

\_\_\_\_\_\_Class methods and variable names use uppercase letters as
word separators with

> the first character is not capitalized

\_\_\_\_\_\_Private class data member names are prepended with the
underscore, the rest is

> the same as method names

\_\_\_\_\_\_static const data members are all uppercase

\_\_\_\_\_\_typedef names reflect the style appropriate to the
underlying type

\_\_\_\_\_\_Class, struct, variable, and method names that differ by
case only are not used

\_\_\_\_\_\_C function names follow the *OHD C Programming Standards and
Guidelines*

### Class Design

\_\_\_\_\_\_Class members are declared in this order: public members,
protected members,

> private members

\_\_\_\_\_\_Data members are properly protected (declared as private or
protected)

\_\_\_\_\_\_Classes (except functors and static classes) implement a
default constructor, a

> virtual destructor, a copy constructor, and an overloaded assignment
> operator

\_\_\_\_\_\_Static classes declare a private default constructor to
prevent instantiation

### Safety and Performance

\_\_\_\_\_\_Type conversions have been done explicitly. The C++ set of
casting operators

> static_cast, reinterpret_cast, const_cast and dynamic_cast have been
> used instead of C-style casting

\_\_\_\_\_\_Global variables are not used except in rare cases and when
used include an inline

> comment describing the reason for use.

\_\_\_\_\_\_Dynamically allocated memory is deallocated when no longer
needed

\_\_\_\_\_\_There is no dangling pointers. Pointers are always tested
for NULL values before

> trying to dereference them

\_\_\_\_\_\_There is no hardcoded numerical values, const or enum type
values are used

> instead

\_\_\_\_\_\_Large objects are created on the heap

\_\_\_\_\_\_The arguments specified in a function prototype are
associated with variable

> names

#  C++ Programming Guidelines

## Readability and Maintainability

\_\_\_\_\_\_A space is put between the parenthesis and the keywords or
the function names

\_\_\_\_\_\_A space is put between variables, keywords and operators

\_\_\_\_\_\_Pointers are named in some fashion that distinguishes them
from other

> "ordinary" variables

\_\_\_\_\_\_Parentheses are used in macros to ensure correct evaluation
of the macro

\_\_\_\_\_\_The goto statement is used very sparingly

### User Defined Types

\_\_\_\_\_\_static const members are used instead of #defined constants

\_\_\_\_\_\_Proper typedefs are used instead of using templates directly

\_\_\_\_\_\_enum is used to define a collection of integral constants

### Variables

\_\_\_\_\_\_const correctness has been practiced

\_\_\_\_\_\_All variables are correctly initialized

\_\_\_\_\_\_Local variables are declared near their first use.

\_\_\_\_\_\_The copy constructor is used to construct an object instead
of the assignment

> operator (=)

### Performance

\_\_\_\_\_\_inline functions are used instead of Macros

\_\_\_\_\_\_The prefix form (++i or \--i) is used instead of postfix
form (i++ or i\--)

\_\_\_\_\_\_Pointer arithmetic has been avoided

\_\_\_\_\_\_Repetitive computations are reduced by only doing them once
and saving the

> result in a temporary variable for future access

### Class Design

\_\_\_\_\_\_Parts-of relation inheritance has been avoided

# Reviewer's Comments: