Use tabs instead of spaces (MonoDevelop default).
Any curly brace defining control flow, scope, or the bounds of a implementation goes on its own line.
Do not use single line if statements.
if (this.enabled)
{
// …
}
else
{
// …
}
All named values should be given descriptive names which indicate their use clear enough that one can understand their role in the program without detailed inspection. Favor clear names which state the purpose of the variable over short names.
GameObject obj; // how do we use this? what does it represent?
GameObject player; // clear intent and representation
Common words can be abbreviated, such as “temp“ for “temporary”. Variables used solely for iteration, or as parameters in pure mathematical functions can be given short names, such as “i”.
Variable, parameter, field, and property names use lowerCamelCase. Constant names use SCREAMING_SNAKE_CASE.
Define variables alongside their type. Do not use the var
keyword.
GameObject pivotTarget = GameObject.Find (“door”);
for (int i=0; i < ATTEMPT_COUNT; i++)
{
// …
}
All methods have descriptive names which indicate their functionality and side effects clearly. Favor descriptive names over short ones.
Method names are written in UpperCamelCase.
A Get and Setter pair for a field should typically be replaced with a C# property.
If a method has the potential to return null
, specify it in the documentation.
A call to a method should have a space character separate the name of the method from the parameter list.
Name a class with clarity in what it does, or what data it represents.
Runtime script classes can often use verbs in their name (such as TumbleInteraction
) but should refrain from verb phrases (such as StartTumblingInteraction
).
Static classes defined solely for providing static extension methods should have the suffix “Extensions” and a prefix which defines what they class they extend.
When referencing a field, property or method of the current this
object, use the keyword this
. It is clearer where the variable or functionality comes from. Additionally, the this
style is the only way to properly call an extension method.
if (this.enabled)
{
this.ActivateLazer (true);
}
Use a foreach
block in the place of an for
block wherever possible. It is easier to read, and less prone to off-by-one errors.
Specify the access level of code elements. Do not make elements public unless they are critical to other API or need to be directly edited by our users in the Unity Inspector. Use the [HideInInspector]
annotation to hide public fields/properties from end users if it is not appropriate for them to edit them.
Use the C# documentation markup on publicly defined code elements.