top of page

Unity C# Code quality guide

As you already know, the code is the most important part of every project. It's crucial to understand, that when your delivery is being checked/assessed, the greatest attention is paid to the code. It's totally not enough just to make the game work, the code should look perfect.

By following this guide, you will improve the quality of your code and progress faster in the practice of game programming. Here you will find the main points that you need to pay special attention to when creating projects and the improvements suggestions.


Naming

Namespaces

  • Don't forget to place every type that you define into the namespace it belongs to. Examples: 

    • GameName.Infrastructure

    • GameName.Gameplay.Views

    • GameName.DayaLayer

    • GameName.Infrastructure.Networking

    • GameName.Utils

    • . . .

  • For Unity projects It's recommended that all the namespaces begin with the name of the game


Classes

  • Always invest a great effort into deciding on the classes' responsibilities.

  • Archilense guide will help you to make better decisions

  • Encapsulation and the access modifiers:

    • Encapsulation: Idea of creating code structures that hide their values and state preventing direct access

    • Make sure your classes expose publicly only the members that need to be accessed by other types

    • Always keep your classes as encapsulated as possible

  • Be consistent in the class members naming​

    • Private fields always start from '_'​

    • Public and protected fields and properties follow PascalCasing

    • Method names follow PascalCasing

  • Always group the members of the same type. #region helps to group the members and keep the code clean

  • Keep consistent class members order. As an example, you can stick to the following members order:

    1. Constants​

    2. Events

    3. Fields

    4. Constructors

    5. Methods

    6. Properties

    7. Microsoft C# members order guide

  • We suggest to use 'var' keyword when defining local variables where it's possible


Statics

We use statics when we want to provide global, project-wide access to the type's functionality. Despite their convenience, statics hide several dangers:

  • The garbage collector (GC) threats all static objects in a spacial way. Without a special threat, there is always a danger of static object not being collected by the GC.

  • There is always a risk of All the object referenced by static objects not being collected as well

  • Therefore, always keep an eye on statics

    • use them only when there is no other way to achieve access to the type in any other way

    • use them when the static type contains only members of primitive or value types (not reference types)


Singletons

  • Singletons are special case of the Statics. There are the same dangers 

  • There are two reasons to use singletons

    • global access to the singleton instance

    • only one, single instance of the type exists in the memory

  • Singletons hides the same dangers as the Statics.​


Clear code

Always strive to produce clear code. This is what differentiates the code written by a professional and code created by a beginner. Following are the key characteristics of the clear code:

  • Easy to understand, keep in mind the potential reader of the code

  • Self explanatory code

  • Simple code

  • Clear code doesn't require any comments

  • Meaningful and descriptive names

  • Small functions with clearly defined responsibilities

  • Name of the function clearly communicates what the function does

  • Avoid a deep code nesting (IF inside IF, inside IF, etc.)

  • Break down complex logic into smaller. simpler pieces

  • Remove dead code. Always remove unused and commented-out code

מזהים בעיה כלשהי? נא צור איתנו קשר

bottom of page