Table of contents

• Introduction
  • Goals
• Languages
  • C++
  • GLSL
• Automation
  • MVS

Introduction

The coding standard described in here outlines various guidelines for writing code. These guidelines should be adhered to as much as possible in order to submit code to the repository.

Goals

There are a few goals that we can aim for in order to keep the codebase easy to understand and maintain.

• Consistency is key: code changes should reflect the standard.
• Be explicit: show consideration to each other by being a bit more explicit when naming functions or variables.

Languages

C++

Code written in C++ should follow these guidelines.

Example of Foo.hpp

class Foo
{
public:
    Foo();
  
    void Update(double aDeltaTime);

private:
    int myDeltaTimeAccumulator;
};

Example of Foo.cpp

#include "Foo.hpp"

Foo::Foo()
    : myDeltaTimeAccumulator(0)
{}

void Foo::Update(double aDeltaTime)
{
    myDeltaTimeAccumulator += aDeltaTime;
}

Style

• Indentation should 1 Tab (4 spaces).
• Braces should be placed on newlines.
• Don't align indentation that results in separate columns of code (declaration).
• Single-expression statements and loops may leave out braces, as well as single-line functions.
• Prefer using 1 space to separate arguments.
• Apply rules for padding class members by ordering them from largest to smallest.
• Make use of forward deceleration in header files.
• Prefer writing descriptive code over comments in code.

Naming

Member variable names should be prefixed with my. Variable names should use camel case including the prefix. Functional Parameters/arguments should be prefixed with a. Local-scope variables should be named using camel case.

class Foo
{
public:
   Foo();

   void Bar(const std::string& aBarName);

private:
   int myBarName;
};

Pointer and reference placement

For simple pointers or references, the asterisk or ampersand symbol is considered part of the type and should be placed immediately after the type name. When type modifiers are added to the right of type it may affect the placement of the asterisk or ampersand, in this case spacing is allowed. When using compound pointers or references, take care where the modifier is so that it's making the correct part constant.

Type* foo;
Type& bar;
Type const* fooBar;

Enumerators

Both un-scoped (global) and scoped enumerators should be declared using pascal case. Each entry in the enumerators should be pascal case as well.

enum class WeekDays
{
   Monday,
   Tuesday
};

Constants

Defined constants/macros should be declared using capitalized characters and underscores to separate words.

#define FOO_BAR 64

Functions

Function names should be declared using pascal case.

bool Foo::GetBarName() const;

GLSL

Shading languages, or at least GLSL, should follow these guidelines.

Braces should be inline Indentation should be 1 Tab (4 spaces). Variables are named using camel case. Class names are named using pascal case. In and out variables should use the corresponding prefix. Uniforms should be named like local scope variables using camel case. File structure should be layout, in, out, uniform, main in that order. At the top of a shader it should declare the type and version.

Example of vertexShader.glsl

// VERTEX SHADER
#version 330

layout(location = 0) in vec3 inVertexPosition;

out VertexData {
    vec3 worldPosition;
    vec3 color;
} outVertexData;

uniform mat4 projectionMatrix;
uniform mat4 viewMatrix;

void main() {
    outVertexData.worldPosition = projectionMatrix * viewMatrix * vec4(inVertexPosition, 1);
    gl_Position = outVertexData.worldPos;
    outVertexData.color = vec3(inVertexPosition.z);
}

Automation

MVS

The guidelines can be automatically applied by modifying preferences in Microsoft Visual Studio.