Style Guide - VoxelGameDev/OpenVox GitHub Wiki

Naming

Local/Public Variables

Local/Public variables will be Camel Case. Ex: myVar

Private Variables

Private and protected variables will be Camel Case with an "m_" in front. Ex: m_myVar

Functions

Functions (all of them) are also Camel Case. Ex: myFunc()

Classes

Class names will be Pascal Case. Ex: MyClass

Constants

Constants are all caps, separated by underscores. Ex: MY_CONSTANT

Enums

Enum names are Pascal case, and values are written like constants. We use enum classes instead of just enums.

//For small enums
enum class MyEnum {  ENUM_1, ENUM_2 };

//For large enums
enum MyEnum {  
    ENUM_1, 
    ENUM_2,
    ...
};

//Then to call an enum, you use
MyEnum::ENUM_1;

Switch Blocks

Switch blocks should be organized with the following indentation. They should also attempt to use default whenever possible.

switch (value) {
case 0:
case 1:
    // Code
    break;
case 2:
    // Code
    break;
default:
    // Code
    break;
}

Pointers and References

C++ pointers and references should have their reference symbol next to the type rather than to the name.

float* savePercentages; 
// NOT: float *savePercentages; or float * savePercentages; 

int& numCups;   
// NOT: int &numCups; or int & numCups;

Object Name

The name of the object is implicit, and should be avoided in a method name.

puck.getDensity();    // NOT: puck.getPuckDensity();

Terms Get/Set

The terms get/set may be used where an attribute is accessed directly.

player.getNumber();  
player.setNumber(number);  
stick.getFlex();
stick.setFlex(flex);

Term init

The term initshould be used where an object or a concept is established.

rink.initPaintedLines();  
video.initOnScreenScore();

Variables representing GUI components

Variables representing GUI components should be suffixed by the component type name. Ex: scoreboardText, mainWindow, fileMenu

Iterator variables

Iterator variables should be called i, j, k ect. or y, z, x`, depending on how they are used

//iterating through an array
for (int i = 0; i < numGoals); i++) {
    goals[i].playVideo();
}
//Iterating through a chunk
for (int y = 0; y < CHUNK_WIDTH; y++) {
    for (int z = 0; z< CHUNK_WIDTH; z++) {
        for (int x = 0; x < CHUNK_WIDTH; x++) {
        …

Prefix is

The prefix is should be used for boolean variables and methods. isGoodGoal, isRetired, isWinningTeam. Occasionally the has, can, should, in, and want prefixes will be better choices.

Complement names

Complement names must be used for complement operations get/set, add/remove, create/destroy, start/stop.

Abbreviations in names should be avoided.

computeGoalsAgainstAverage();  // NOT: compGlsAgstAvg();  

Naming pointers specifically should be avoided.

Puck* puck; // NOT: Puck* puckPtr;

Negated boolean variable names must be avoided.

bool isRetired; // NOT: isNotRetired or isNotPlaying

Includes

In header files, use minimal includes and forward declaration if possible. In source files, includes should be laid out in the following block order, and A-Z within blocks (except for the first two includes):

#include "stdafx.h"
#include "HeaderForMyFileIfItExists.h"

#include <systemfiles>
#include <standardfiles.h>

#include <ThirdParty/dependencies.h>
#include <ExternalProjectReferences.h>

#include "MyProjectFiles.h"

If you have to use them, enum constants should be prefixed by a common type name.

enum Jersey {
  JERSEY_HOME,
  JERSEY_AWAY,
  JERSEY_ALTERNATE
};

macros should be all caps separated by _

Engine Header Files

Header files should be surrounded by the following code on creation:

//
// $FILE_BASE$.$FILE_EXT$
// VGD Engine
//
// Created by YOURNAME on $DAY$ $MONTHNAME$ $YEAR$
//

/*! \file $FILE_BASE$.$FILE_EXT$
* @brief $end$ SHORTDESCRIPTION
*/

#pragma once

// FILE CODE

.h files

Files that are declaration only, or with very little implementation. Usually accompanied by a cpp file if they need implementation.

.hpp files

Files that have implementation such as files for template code should be .hpp instead of .h

.inl files

.inl files can be used to separate implementation from the header for template .hpp files. They should be included at the bottom of the .hpp file and can never be included anywhere else. They don't need include guards.

namespaces

namespaces are lower case.

TODO

TODO's should follow google style guide.

//TODO(YOURNAME): ...

The name is not an assignment, it merely shows who created the TODO so other programmers can know without needing to check blame.

Files

Source code is PascalCase, data files are snake_case

Directories

Directories are snake_case