This style guide is based on C# and Unity conventions.
On the whole, naming should follow C# standards.
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
Written in PascalCase. For example RadialSlider
.
Methods are written in PascalCase. For example DoSomething()
.
Arrange_Act_Assert
EXAMPLE:
GivenAnEmptyDb_CreatingAJob_ShouldStoreTheRecordInTheDb
Properties are written in PascalCase. For example FirstName { get; set; }
.
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 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()
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;
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;
Declare local variables using the var keyword when the type can be implicitly inferred.
BAD:
string username = "johndoe";
GOOD:
var username = "johndoe";
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
All interfaces should be prefaced with the letter I.
BAD:
RadialSlider
GOOD:
IRadialSlider
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 120 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 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;
}
Use US English spelling.
BAD:
var colour = "red";
GOOD:
var color = "red";