dbasilioesp/StyleGuideCppGames.md

## StyleGuideCppGames.md

      
    Raw
  

              StyleGuideCppGames.md
            
          
    Style Guide C++ for Games

Introduction

This is a suggestion of how you should develop with the C++ language.

Style Guides are about consitency for the code and often more important in a project.
Code in Zen Mode

Most of this rules I have learned from python phylosophy: [Zen of Python](http://c2.com/cgi/wiki?PythonPhilosophy .)

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
NameSpaces are one honking great idea -- let's do more of those!

Indentation

Use EditorConfig for everyone to have consistency.
Maximum Line Length

Limit all lines to a maximum of 120 characters.
Blank Lines

Separate the functions, classes and big scopes always with 2 blank lines. Like this:
void foo(){

}


void bar(){

}

And inside the scope of functions, separate the code in logical blocks. After the if, for, while put 1 blank line and maybe before it, just what you more like.
int age = 48;

if(age){
    ...
}
// 1 blank line here
Imports

Don´t try to reuse the imports libraries, this will difficult to other developers from where some functions and variables are coming.
Like this:
Good
// File 1
#include <iostream>
// File 2
#include <iostream>
#include "file1.h"
Bad
// File 1
#include <iostream>
// File 2
#include "file1.h"

// In this way, where is the header iostream coming from? Can be from anywhere.
Order

Include the libraries in this order:

Standard library imports
Related third party imports
Local application/library specific imports

#include <iostream>   // standard library
#include <GL/glut.h>  // third party library
#include "File1.h"    // application library (your code)
Namespace std

Always declare the namespace std after the imports block. In this way, your code will be much more readable.
#include <iostream>

using namespace std;

Whitespace in Expressions and Statements

// one space between each parameter of a function
Yes: foo(1, 2, 3);
No:  foo(1,2,3);

// separate operators from the variables and values
Yes: if(width == 200)
No:  if(width==200)

// name of function together with the brackets
Yes: foo(1, 2, 3);
No:  foo (1, 2, 3);

// separate the operations
Yes: i = i + 1;
No:  i=i+1;

// when the separation causes even more confusion, group it

Yes: hypot2 = x*x + y*y;
No:  hypot2 = x * x + y * y;

Yes: c = (a+b) * (a-b);
No:  c = (a + b) * (a - b);

// break the sentences
if(alpha == beta &&
   omega != delta &&
   gama == psi)
{
	// ...
}

Comments

Use one space after initiate the comment:
// CamelCase signs something important like a topic

// lowercase signs a explanation
Naming Conventions

Class Names

Use CamelCase convention.
Yes
class Gold {
    // ...
}
No
class gold {
    // ...
}
Functions and Methods Names

It is hard to create consistency with functions and methods names because a lot of external libraries for C++ like Glut and Box2D follow their own conventions. But you are free to follow this pattern:
For functions use CamelCase.
void CreateBox(){
    // ...
}
For methods use lowerCase:
class Gold {
    int getQuantity();
};
File Names

Use CamelCase convention or lowercase with words separated by underscores as necessary to improve readability.
Variable Names

Your code must be semantic and readble for anyone in anytime. If you follow the principle of design for text, you will be in the right path: Proximity, Alignment, Contrast and Repetition.
Abbreviations

Abbreviations causes a lot of confusion for who is not accustomed with the context of your code, but don't confuse abbreviation with namespace that have other proposal.
Use width and height names instead of w and h.
Good
int width;
int height;
Bad
int w;
int h;
Counters

Use the sufix Count to say that these are counters.
int pigsCount = 0;
int birdsCount = 0;

void CreateBird(){
  ...
  birdsCount++;
}

Others Style Guides


Python PEP 8
Mozilla Coding Style