Skip to content

Instantly share code, notes, and snippets.

@deniskyashif
Last active October 18, 2018 13:38
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save deniskyashif/97336f214547b01b80b418c66b70b429 to your computer and use it in GitHub Desktop.
Save deniskyashif/97336f214547b01b80b418c66b70b429 to your computer and use it in GitHub Desktop.

Prevalent Inc. C# Style Guide

This style guide is based on C# and Unity conventions.

Table of Contents

Nomenclature

On the whole, naming should follow C# standards.

Namespaces

Namespaces are all PascalCase, multiple words concatenated together, without hyphens ( - ) or underscores ( _ ). The exception to this rule are acronyms like GUI or HUD, which can be uppercase:

BAD:

cortx.data.models

GOOD:

CortX.Data.Models

Classes & Interfaces

Written in PascalCase. For example RadialSlider.

Methods

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

Test Methods

Arrange_Act_Assert

EXAMPLE:

GivenAnEmptyDb_CreatingAJob_ShouldStoreTheRecordInTheDb

Properties

Properties are written in PascalCase. For example FirstName { get; set; }.

Fields

All non-static fields are written camelCase. Per Unity convention, this includes public fields as well.

For example:

public class MyClass 
{
    public int publicField;
    int packagePrivate;
    private int myPrivate;
    protected int myProtected;
}

BAD:

private int _myPrivateVariable

GOOD:

private int myPrivateVariable

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

public static int TheAnswer = 42;

Parameters

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

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

Events

Events should be written in PascalCase. Never prefix events with a prefix like On.

BAD:

public static event CloseCallback OnClose;

GOOD:

public static event CloseCallback Close;

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;

Declare local variables using the var keyword when the type can be implicitly inferred.

BAD:

string username = "johndoe";

GOOD:

var username = "johndoe";

Classes

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

By default classes should always be internal and sealed until there's an explicit reason to be otherwise.

When accessing a class instance member, always use the this keyword.__

BAD

FirstName = "John";

GOOD:

this.FirstName = "John";

Ordering:

  • Within a class, struct or interface: (SA1201 and SA1203)

    • Constant Fields
    • Fields
    • Constructors
    • Finalizers (Destructors)
    • Delegates
    • Events
    • Enums
    • Interfaces
    • Properties
    • Indexers
    • Methods
    • Structs
    • Classes
  • Within each of these groups order by access: (SA1202)

    • public
    • internal
    • protected internal
    • protected
    • private
  • Within each of the access groups, order by static, then non-static: (SA1204)

    • static
    • non-static

Within each of the static/non-static groups of fields, order by readonly, then non-readonly : (SA1214 and SA1215) * readonly * non-readonly

  • An unrolled list is 130 lines long, so I won't unroll it here. The methods part unrolled
    • public static methods
    • public methods
    • internal static methods
    • internal methods
    • protected internal static methods
    • protected internal methods
    • protected static methods
    • protected methods
    • private static methods
    • private methods

Interfaces

All interfaces should be prefaced with the letter I.

BAD:

RadialSlider

GOOD:

IRadialSlider

Spacing

Indentation

Indentation should be done using spaces — never tabs.

Blocks

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);
}

Line Wraps

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

Line Length

Lines should be no longer than 120 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

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

Switch-statements come with default case by default (heh). If the default case is never reached, be sure to remove it.

DEFAULT GETS USED:

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

DEFAULT DOESN'T GET USED:

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

Language

Use US English spelling.

BAD:

var colour = "red";

GOOD:

var color = "red";
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment