Style guide

Table of Contents


1. User Interface Style Guide

1.1. Prompts before inputs

Before using an input statement (e.g., cin), use an output statement (e.g., cout) to display a message to the user. Make sure you're clear about what kind of data you're expecting them to enter.

No:

_

If you use an input statement it doesn't show anything on the screen, so it looks like your program has crashed.

Yes:

Please enter pet name: _

Use an output statement to display a message before getting the user's input.


2. C++ Style Guide

2.1. Naming conventions

Variables

lowerCamelCase - Variable names should begin with a lower-case letter and each subsequent letter use an Upper Case, in a camel-case format.

Additionally:

  • Variable names should be descriptive.
  • Avoid using single-letter variable names except with for loops.
Member variables
m_lowerCamelCase - Variables that belong to a class should be prefixed with m_ to signify "member".
Functions
CamelCase - Function names should begin with an upper-case letter and be in CamelCase form. In some cases, using an underscore might be okay to group like-functions together, if it makes things more clear.
Classes
CamelCase - Class names should begin with an upper-case letter and be in CamelCase form.

2.2. File organization

Function/class declarations
Function and class declarations should go in a header (.h) file.
Function definitions
Function definitions should go in a source (.cpp) file, EXCEPT TEMPLATED FUNCTIONS (those all go in .h).

2.3. Clean code

Whitespace
Adequate whitespace should be used to differentiate logical sections of code. At the same time, don't use too much whitespace. The goal is to have readable code.
If ( true ) return true; else return false;
If you're writing a condition to check if something is true in order to return true, just return the result of the condition instead.

No:

if ( a == b )
  return true;
else
  return false;

Yes:

return ( a == b );

2.4. Curly braces

Follow the existing code base
  • If you're writing code from scratch you can follow whatever style you'd like as long as it is consistent.
  • When working with existing code-bases, use the same style as the existing code.
  • See https://en.wikipedia.org/wiki/Indentation_style for indentation styles

Preferred style:

if ( a == b )
{
  DoThing();
}

GNU styling:

if ( a == b )
  {
    DoThing();
  }

K&R Styling ("JavaScript" style):

if ( a == b ) {
  DoThing();
}
One-line contents
Always surround your if statement and while loop contents within curly braces { } even though it's not required for one-line internals.

No:

if ( CONDITION )
  DoThingA();
else if ( CONDITION2 )
  DoThingB();
else
  DoThingC();

Yes:

if ( CONDITION )
{
  DoThingA();
}
else if ( CONDITION2 )
{
  DoThingB();
}
else
{
  DoThingC();
}

Or:

if      ( CONDITION )  { DoThingA(); }
else if ( CONDITION2 ) { DoThingB(); }
else                   { DoThingC(); }

2.5. Cross-platform support

File guards
Always use ifndef instead of pragma once for your file guards.

Yes:

#ifndef _MYFILE_H
#define _MYFILE_H 

// My code

#endif

No:

#pragma once

// My code

2.6. Best practices

  • NEVER USE GLOBAL VARIABLES.
  • NEVER USE goto STATEMENTS.

Author: Rachel Wil Sha Singh

Created: 2023-10-20 Fri 14:31

Validate