Xelex Digital's C# Style Guide

This guide was taken mostly from Ray Wenderlich's very well structured c-sharp-style-guide with a bit closer adherence to Microsoft's Coding Conventions. We're also utilizing ASPNet's Engineering Guidelines here.

Quick Reference

Naming

• naming should follow Microsoft's Guidelines

Layout

• one statement or declaration per line
• generally prefer curly braces on their own line, with exceptions
• no braces for single line conditional statements
• always use braces for conditional statements spanning multiple lines
• one blank line between method definitions and property definitions
• 100 characters per line
• spaces for indentation rather than tabs
• indent 4 spaces
• indent an additional 4 spaces for line wraps

Language

• prefer var over explicit type (var foo = "bar"; over string foo = "bar";)
• avoid using this unless absolutely necessary
• use _camelCase for private fields
• specify member visiblity (private string _foo; not string _foo;)
• prefer C# type keywords over .NET type names (string over String)

Table of Contents

• Quick Reference
• 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

Nomenclature

On the whole, naming should follow C# standards.

Namespaces

Namespaces are all UpperCamelCase, multiple words concatenated together, without hypens or underscores:

BAD:

com.webchartmd.fpsgame.hud.healthbar

GOOD:

WebChartMD.FPSGame.HUD.Healthbar

Classes & Interfaces

Written in UpperCamelCase. For example RadialSlider.

Methods

Public methods are written in UpperCamelCase. For example DoSomething.

Private methods are written in lowerCamelCase. For example: doSometing

Fields

Public and protected fields are written lowerCamelCase.

For example:

public class MyClass 
{
    public int publicField;
    private int _packagePrivate;
    private int _myPrivate;
    protected int myProtected;
}

Use _camelCase for private fields.

BAD:

private int myPrivateVariable

GOOD:

private int _myPrivateVariable

Parameters

Parameters are written in lowerCamelCase.

BAD:

private void doSomething(Vector3 Location)

GOOD:

private void doSomething(Vector3 location)

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

Delegates

Delegats are written in UpperCamelCase.

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()

Events

Prefix event methods with the prefix On.

BAD:

public static event CloseCallback Close;

GOOD:

public static event CloseCallback OnClose;

Misc

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

BAD:

XMLHTTPRequest
string URL
findPostByID

GOOD:

XmlHttpRequest
string url
findPostById

Declarations

Access Level Modifiers

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

Fields & Variables

Prefer single declaration per line.

BAD:

string username, twitterHandle;

GOOD:

string username;
string twitterHandle;

Prefer var over explicit types where type can be reasonably inferred. This promotes readability and clarity of variables.

BAD:

string foo = "Bar";
SomeAwesomeType foo = new AwesomeType();

GOOD:

var foo = "Bar";
var foo = new AwesomeType();

Classes

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

Interfaces

All interfaces should be prefaced with the letter I.

BAD:

RadialSlider

GOOD:

IRadialSlider

Spacing

Indentation

Indentation is using spaces - never tabs (configure VS to convert tabs to spaces).

Blocks

Indentation for blocks uses 4 spaces:

BAD:

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

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

GOOD:

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

Line Wraps

Indentation for line wraps should use an additional 4 spaces from the originating line:

BAD:

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

GOOD:

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

Line Length

Lines should be no longer than 100 characters long.

Vertical Spacing

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.

Brace Style

Curly braces are preferred on their own line, with exceptions for loops, object initialization and similar cases:

BAD:

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

GOOD:

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

Singe line conditional statements don't uses braces, always use them over multiple lines.

BAD:

if (someTest)
    doSomething();
if (someTest) { doSomethingElse(); }

GOOD:

if (someTest) doSomething();
if (someTest) { 
    doSomethingElse();
}

Switch Statements

Switch statements fall-through by default, but this can be unintuitive. Do not use fall-through behavior.

Alway include the default case.

Language

Use US English spelling.

BAD:

string colour = "red";

GOOD:

string color = "red";