C# Code Style

Summary

C# code style is the set of naming, formatting, and structure conventions a team uses to keep code readable and maintainable. In Unity projects this matters more than it first appears, because many small scripts, assets, and editor workflows interact. Consistent style reduces onboarding time, makes refactors safer, and helps teams spot actual logic problems instead of wasting effort decoding inconsistent code. (Unity, C# Code Style Guide, see source-unity-csharp-style-guide; Unity, Level Up Your Code with Design Patterns and SOLID, see source-unity-design-patterns-and-solid)

Key ideas

• Consistency beats personal taste. A slightly imperfect but shared style guide is better than every file reflecting a different programmer.
• Small methods and small responsibilities are part of style, not just architecture.
• Meaningful names matter more than clever short names.
• Comments should explain intent, not restate obvious code.
• Tooling support such as EditorConfig or formatter settings helps teams keep style stable across IDEs.

In practice

Unity-friendly habits:

• Prefer one clear responsibility per MonoBehaviour.
• Name fields, methods, and assets so that Inspector-facing code remains legible to non-programmers.
• Use constants or wrappers for fragile string-based APIs where possible.
• Keep methods short enough that their role is obvious at a glance.
• Treat UXML, USS, and C# naming as one coordinated system when working with unity-ui-toolkit.

Naming conventions

Use one naming scheme consistently across the project. A simple student-friendly default is:

Thing	Convention	Example
Class	PascalCase	PlayerHealth
Method	PascalCase	TakeDamage()
Property	PascalCase	CurrentHealth
Public field	avoid where possible	use a property or [SerializeField] private instead
Private field	_camelCase	_moveSpeed
Local variable	camelCase	damageAmount
Method parameter	camelCase	int damageAmount
Enum / enum member	PascalCase	GameState.Playing
Interface	IPascalCase	IDamageable
Constant	PascalCase	MaxHealth
Boolean	name like a question	isGrounded, hasKey, canJump

Useful Unity-specific habits:

• Prefer [SerializeField] private fields over public fields when you want Inspector exposure without giving away write access.
• Name Inspector-visible fields clearly enough that a designer can understand them without opening the code.
• Keep filenames aligned with class names for MonoBehaviours and ScriptableObjects.
• For Animator parameters, input actions, tags, and similar string-based systems, use clear constants or wrappers where practical.

Commenting well

Comments are most useful when they explain intent, assumptions, or non-obvious behaviour.

Good things to comment:

• why a piece of code exists
• why a strange-looking value or workaround is necessary
• what assumption a system depends on
• what side-effect another programmer might miss

Things that usually should not be commented:

• obvious line-by-line behaviour
• code whose meaning would be clearer if it were simply renamed
• large blocks of stale explanation that drift out of date

Better than a redundant comment

// Bad: repeats what the code already says
score += 10; // Add 10 to score
 
// Better: either no comment...
score += 10;
 
// ...or explain the design reason
score += 10; // Flat reward keeps early coin values easy to tune

Comment the assumption, not the syntax

// Enemy attacks are disabled during knockback so the player gets a readable recovery window.
if (_isKnockedBack)
{
    return;
}

Use XML comments selectively

Use /// <summary> mainly for:

• public APIs used by other scripts
• methods with non-obvious behaviour or side effects
• reusable helper code you expect other people to call

Do not feel obliged to add XML comments to every tiny private helper if the name already explains it.

Evidence

• Unity’s style guide treats naming, comments, and method structure as collaboration and maintenance tools rather than cosmetic polish. (Unity, C# Code Style Guide, see source-unity-csharp-style-guide)
• Unity’s SOLID/design-patterns e-book reinforces the same lesson from a different angle: the component model works best when responsibilities are small and clear. (Unity, Level Up Your Code with Design Patterns and SOLID, see source-unity-design-patterns-and-solid)

Implications

• Code style is part of project sustainability, not an optional final pass.
• Many “architecture” problems start as style problems: giant scripts, vague names, mixed responsibilities, and hidden dependencies.
• Students who learn clean style early will find later patterns such as interfaces, ScriptableObjects, and decoupled systems easier to understand.
• Strong naming reduces the need for comments; strong comments explain the few things naming alone cannot.

Open questions

• How strict should a student project be about formal style enforcement versus lightweight shared convention?
• Which style rules matter most in a small prototype, and which only become important at team scale?

Related

csharp-methods · csharp-oop-fundamentals · unity-object-communication · unity-ui-toolkit · source-unity-csharp-style-guide · source-unity-design-patterns-and-solid