Stan's Assets Unity C# Coding guidelines


This style guide is based on personal habits + C# and Unity conventions. I can't say it's better or worse than any other style guide you may find. This one was designed based on team personal preferences. I will also try to explain some decisions, where we are not following the standard coding conventions.

Our overarching goals are concisenessreadability, and simplicity. Also, this guide is written to keep Unity in mind.


Classes & Interfaces

Public, Private and Abstract classes in PascalCase. For example Button Interfaces in PascalCase + Iprefix For example IButton


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


  • public, public static -> PascalCase
  • static -> s_ prefix + camelCase
  • private, protected, internal -> m_ prefix + camelCase
  • const -> UPPER_CASE
public class ExampleClass : MonoBehaviour
    public  const int MY_CONST_VALUE = 0;
    private const int MY_CONST_VALUE_2 = 0;

    public int PublicField;
    public static int MyStaticFiled;

    int m_packagePrivate;
    private int m_myPrivate;
    protected int m_myProtected;

    private static int s_myPrivate;


Parameters are written in camelCase.

public void SetPosition(Vector3 position) {
    var newPosition = position;

Motivations: With such structure, you can always tell:

  • Is this filed only for private use or publicly available
  • Is this a static filed or no
  • Is this a constant
  • Is this filed was declared inside a call or it's only a part of the method you are looking at


Prefix event methods with the prefix On.

public event Action OnClose;

If a method is used to handle delegate callback add the suffix **Handler **

void CloseHandler();
void ResetButtonClickHandler();
void PlayerDisconnectedHandler();

Motivations: Just make your code to be more readable for others. Try to explain what your methods are doing.

Brace Style

Only braces for classes and namespaces get their own line.

namespace Example
    public class ExampleClass : MonoBehaviour
        private int m_property;

        public void DoSomethingMethod() {
            if (someTest) {
            } else {

            switch (variable) {
                case 1:
                case 2:

        public int  Property {
            get {
                return m_property;

            set {
                m_property = value;

Motivations: This way we are trying to highlight classes (embedded classes as well) and namespaces. What about inline braces style for everything else, it just makes code smaller. And also this is a personal preference.

Code Structure Rules

This chapter will describe rules that you should stick designing a code structure.

EditorMenu. If you are adding a new Editor menu item, make sure you do this in a separate class, that is inside an Editor folder and has EditorMenu postfix. This will save you a lot of time when you will need to understand what this or that menu item is doing, and which script is adding it.

Reserved Names

When you have a number of plugin or modules in your project, most of the classes are meant to do similar tasks, so it's very helpful when those classes also have a similar names Classes which add new items to a Unity Editor Menu should have EditorMenu* postfix Custom script Inspectors should have the same name as the target class + Inspector* postfix

Plugin Names Convention

Every plugin has a name, and every plugin should have a short name (2-3 symbols). Using that naming convention we can come up with fairly simple naming rules. All examples in this chapter will be built relative to Stan's Assets Support Lib. Stan's Assets Support Lib short name - SA. Lib has sperate modules inside, like Platform Dependent Build - PDB, EditorStylesCollection - ESC The following naming rules should apply:


Plugin_Class.* Example: SA_ExampleClass. Plugin_Submobule_Class.* Example: SA_PDB_ExampleClass, SA_ESC_ExampleClass.


This style guide is a collaborative effort Stan's Assets team members:


User replies

No replies yet