This style guide is different from other you may see, because the focus is centered on readability for print and the web. We created this style guide to keep the code in our projects consistent.

Our overarching goals are conciseness, readability and simplicity. Also, this guide is written to keep Unity in mind.

This style guide is based on C#, Unity conventions, raywenderlich/c-sharp-style-guide.

• Nomenclature
  • Namespaces
  • Classes & Interfaces
  • Methods
  • Fields
  • Parameters
  • Delegates
  • Events
  • Misc
• Declarations
  • Access Level Modifiers
  • Fields & Variables
  • Classes
  • Interfaces
• Spacing
  • Indentation
  • Line Length
  • Vertical Spacing
• Brace Style
• Switch Statements
• Language
• Copyright Statement
• Smiley Face
• Credit

On the whole, naming should follow C# standards.

Namespaces are all PascalCase, multiple words concatenated together, without hypens ( - ) or underscores ( _ ):

BAD:

gmo.fpsgame.hud.healthbar

GOOD:

Gmo.FPSGame.HUD.Healthbar

Written in PascalCase. For example RadialSlider.

Methods are written in PascalCase. For example DoSomething().

All non-static fields are written camelCase. Per Unity convention, this exclude public Fields , the public Fields should be in PascalCase.

For example:

public class MyClass 
{
    public int PublicField; 
    int packagePrivate;
    private int myPrivate;
    protected int myProtected;
    
    public int Count() {return 0;}
    private int size() { return 1; }
}

BAD:

private int _myPrivateVariable

GOOD:

private int myPrivateVariable

Static fields are the exception and should be written in PascalCase:

public static int TheAnswer = 42;

Parameters are written in camelCase.

BAD:

void DoSomething(Vector3 Location)

GOOD:

void DoSomething(Vector3 location)

Single character values are to be avoided except for temporary looping variables.

Delegates are written in PascalCase.

When declaring delegates, DO add the suffix EventHandler to names of delegates that are used in events.

BAD:

public delegate void Click()

GOOD:

public delegate void ClickEventHandler()

DO add the suffix Callback to names of delegates other than those used as event handlers.

BAD:

public delegate void Render()

GOOD:

public delegate void RenderCallback()

Prefix event methods with the prefix On.

BAD:

public static event CloseCallback Close;

GOOD:

public static event CloseCallback OnClose;

In code, acronyms should be treated as words. For example:

BAD:

XMLHTTPRequest
String URL
findPostByID

GOOD:

XmlHttpRequest
String url
findPostById

Access level modifiers should be explicitly defined for classes, methods and member variables.

Prefer single declaration per line.

BAD:

string username, twitterHandle;

GOOD:

string username;
string twitterHandle;

Exactly one class per source file, although inner classes are encouraged where scoping appropriate.

All interfaces should be prefaced with the letter I.

BAD:

RadialSlider

GOOD:

IRadialSlider

Spacing is especially important in raywenderlich.com code, as code needs to be easily readable as part of the tutorial.

Indentation should be done using spaces — never tabs.

Indentation for blocks uses 4 spaces for optimal readability:

BAD:

for (int i = 0; i < 10; i++) 
{
  Debug.Log("index=" + i);
}

GOOD:

for (int i = 0; i < 10; i++) 
{
    Debug.Log("index=" + i);
}

Indentation for line wraps should use 4 spaces (not the default 8):

BAD:

CoolUiWidget widget =
        someIncrediblyLongExpression(that, reallyWouldNotFit, on, aSingle, line);

GOOD:

CoolUiWidget widget =
    someIncrediblyLongExpression(that, reallyWouldNotFit, on, aSingle, line);

Lines should be no longer than 100 characters long.

There should be exactly one blank line between methods to aid in visual clarity and organization. Whitespace within methods should separate functionality, but having too many sections in a method often means you should refactor into several methods.

All braces get their own line as it is a C# convention:

BAD:

class MyClass {
    void DoSomething() {
        if (someTest) {
          // ...
        } else {
          // ...
        }
    }
}

GOOD:

class MyClass
{
    void DoSomething()
    {
        if (someTest)
        {
          // ...
        }
        else
        {
          // ...
        }
    }
}

Conditional statements are always required to be enclosed with braces, irrespective of the number of lines required.

BAD:

if (someTest)
    doSomething();  

if (someTest) doSomethingElse();

GOOD:

if (someTest) 
{
    DoSomething();
}  

if (someTest)
{
    DoSomethingElse();
}

Switch-statements should include the default case. It helps prevent errors on unexpected input especially from web.

BAD:

switch (variable) 
{
    case 1:
        break;
    case 2:
        break;
}

GOOD:

switch (variable) 
{
    case 1:
        break;
    case 2:
        break;
    default:
        break;
}

Use US English spelling.

BAD:

string colour = "red";

GOOD:

string color = "red";

The exception here is MonoBehaviour as that's what the class is actually called.

Not define but not the open source.

NOTE: Do not use smileys in your scripts.

This style guide is a collaborative effort from the most stylish gmo-z.com securities team members:

• Angadpreet Singh
• Thanwarin Pisanprechatam
• Tanachot Techajarupan
• Korakoch Singkam
• Sutean Rutjanalard
• Thanasak Polrak