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.
- naming should follow Microsoft's Guidelines
- 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
- prefer
var
over explicit type (var foo = "bar";
overstring foo = "bar";
) - avoid using
this
unless absolutely necessary - use
_camelCase
for private fields - specify member visiblity (
private string _foo;
notstring _foo;
) - prefer C# type keywords over .NET type names (
string
overString
)
On the whole, naming should follow C# standards.
Namespaces are all UpperCamelCase, multiple words concatenated together, without hypens or underscores:
BAD:
com.webchartmd.fpsgame.hud.healthbar
GOOD:
WebChartMD.FPSGame.HUD.Healthbar
Written in UpperCamelCase. For example RadialSlider
.
Public methods are written in UpperCamelCase. For example DoSomething
.
Private methods are written in lowerCamelCase. For example: doSometing
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 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.
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()
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;
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();
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
Indentation is using spaces - never tabs (configure VS to convert tabs to spaces).
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);
}
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);
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.
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 fall-through by default, but this can be unintuitive. Do not use fall-through behavior.
Alway include the default
case.
Use US English spelling.
BAD:
string colour = "red";
GOOD:
string color = "red";