While there might not be one right way to format your C# code, agreeing on a consistent style across your team can result in a cleaner, more readable and scalable codebase. This page offers tips and key considerations to keep in mind for your classes, methods, and comments when creating your own style guide.
Note: The recommendations shared here are based on those provided by Microsoft. The best code style guide rules are the ones that work for your team’s needs.
You can find a code style guide example here or download the full e-book, Use a C# style guide for clean and scalable game code (Unity 6 edition).
Along with naming, formatting helps reduce guesswork and improves code clarity. By following a standardized style guide, code reviews become less about how the code looks and more about what it does.
Omit, expand, or modify these example rules to fit your team’s needs.
In all cases, consider how your team will implement each formatting rule and then have everyone apply it uniformly. Refer back to your team’s style to resolve any discrepancies.
Consider each of the following code formatting suggestions when setting up your Unity dev style guide.
A property provides a flexible mechanism to read, write, or compute class values. Properties behave as if they were public member variables, but in fact they’re special methods called accessors. Each property has a get and set method to access a private field, called a backing field.
In this way, the property encapsulates the data, hiding it from unwanted changes by the user or external objects. The getter and setter each have their own access modifier, allowing your property to be read-write, read-only, or write-only.
You can also use the accessors to validate or convert the data (e.g., verify that the data fits your preferred format or change a value to a particular unit).
The syntax for properties can vary, so your style guide should define how to format them. Use these tips to keep properties consistent in your code.
Use expression-bodied properties for single-line, read-only properties (=>): This returns the private backing field.
Everything else uses the older { get; set; } syntax: If you just want to expose a public property without specifying a backing field, use the Auto-Implemented Property. Apply the expression-bodied syntax for the set and get accessors. Remember to make the setter private if you don’t want to give write access. Align the closing with the opening brace for multi-line code blocks.
Script serialization is the automatic process of transforming data structures or object states into a format that Unity can store and reconstruct later. For performance reasons, Unity handles serialization differently than in other programming environments.
Serialized fields appear in the Inspector, but you cannot serialize static, constant, or read-only fields. They must be either public or tagged with the [SerializeField] attribute. Unity only serializes certain field types, so refer to the documentation page for the complete set of serialization rules.
Observe a few basic guidelines when working with serialized fields:
Reference this serializable class from another class. The resulting variables appear within collapsible units in the Inspector.
There are two common indentation styles in C#:
There are variations on these indentation styles as well. The examples in this guide use the Allman style from the Microsoft Framework Design Guidelines. Regardless of which one you choose as a team, make sure everyone follows the same indentation and brace style.
The indentation is typically two or four spaces. Get everyone on your team to agree on a setting in your Editor preferences without igniting a tabs versus spaces flame war. Note that Visual Studio provides the option to convert tabs to spaces.
In Visual Studio (Windows), navigate to Tools > Options > Text Editor > C# > Tabs.
On Visual Studio for Mac, navigate to Preferences > Source Code > C# Source Code. Select the Text Style to adjust the settings.
Don’t omit braces – not even for single-line statements. Braces increase consistency, which makes your code easier to read and maintain. In this example, the braces clearly separate the action, DoSomething, from the loop.
If later you need to add a Debug line or to run DoSomethingElse, the braces will already be in place. Keeping the clause on a separate line allows you to add a breakpoint easily.
Don’t remove braces from nested multiline statements. Removing braces in this case won’t throw an error, but will likely cause confusion. Apply braces for clarity, even if they’re optional. Braces also ensure that modifications, such as adding new logic, can be done safely without needing to refactor the surrounding structure.
Formatting can vary, so document your team preferences in your style guide and standardize your switch statements accordingly.
Here is one example where you indent the case statements. It’s generally recommended to include a default case as well. Even if the default case is not needed (for example, in cases where all possibilities are covered), including one ensures that the code is prepared to handle unexpected values.
Something as simple as spacing can enhance your code’s appearance onscreen. Your personal formatting preferences can vary, but try the following suggestions to improve readability.
Add spaces to decrease code density. The extra whitespace can give a sense of visual separation between parts of a line improving readability.
Use a single space after a comma between function arguments.
Don’t add a space after the parenthesis and function arguments.
Don’t use spaces between a function name and parenthesis.
As much as possible, avoid spaces inside brackets.
Use a single space before flow control conditions and add a space between the flow comparison operator and parentheses.
Use a single space before and after comparison operators.
Keep lines short. Consider horizontal whitespace: Decide on a standard line width (80-120 characters). Break a long line into smaller statements rather than letting it overflow.
Maintain indentation/hierarchy: Indent your code to increase legibility.
Don’t use column alignment unless needed for readability: This type of spacing aligns the variables but can make it difficult to pair the type with the name.
Column alignment, however, can be useful for bitwise expressions or structs with a lot of data. Just be aware that it may create more work for you to maintain the column alignment as you add more items. Some auto-formatters might also change which part of the column gets aligned.
You can use the vertical spacing to your advantage as well. Keep related parts of the script together and use blank lines to your advantage. Try these suggestions to organize your code from top to bottom:
Keep this to a minimum and note on your style guide where applicable.
Using regions in your code
The #region directive enables you to collapse and hide sections of code in C# files, making large files more manageable and easier to read.
However, if you follow the general advice for Classes from this guide, your class size should be manageable and the #region directive superfluous. Break your code into smaller classes instead of hiding code blocks behind regions. You will be less inclined to add a region if the source file is short.
Note: Many developers consider regions to be code smells or anti-patterns. Decide as a team on which side of the debate you fall.
Don’t despair if these formatting rules seem overwhelming. Modern IDEs make it efficient to set up and enforce them. You can create a template of formatting rules and then convert your project files at once.
To set up formatting rules for the script editor:
If at any time you want to force your script file to conform to the style guide:
On Windows, you can also share your editor settings from Tools > Import and Export Settings. Export a file with the style guide’s C# code formatting and then have every team member import that file.
Visual Studio makes it easy to follow the style guide. Formatting then becomes as simple as using a hotkey.
Note: You can configure an EditorConfig file instead of importing and exporting Visual Studio settings. Doing this allows you to share formatting more easily across different IDEs, and it has the added benefit of working with version control. See the .NET code style rule options for more information.
Though this isn’t specific to clean code, be sure to check out 10 ways to speed up your programming workflow in Unity with Visual Studio. Clean code is much easier to format and refactor if you apply these productivity tips.
To set up an .editorconfig file in Visual Studio Code, follow these steps:
Here’s an example configuration for C#:
# top-most EditorConfig file
root = true
# Unix-style newlines with a newline ending every file
[*]
end_of_line = lf
insert_final_newline = true
# 4 space indentation
[*.cs]
indent_style = space
indent_size = 4
charset = utf-8
trim_trailing_whitespace = true
# Tab indentation for Makefiles
[Makefile]
indent_style = tab
# Specific settings for JSON files
[*.json]
indent_style = space
indent_size = 2
Learn more about naming conventions here or check out the full e-book. You can also explore our detailed code style guide example.
