Code Style & Development Standards

Table of Contents

1. Architecture
   • 1.1 MVVM in Unity
   • 1.2 SOLID Principles
   • 1.3 Common Design Patterns
2. Code Style
   • 2.1 Naming Conventions
3. Commenting & Documentation
   • 3.1 Inline Comments
   • 3.2 XML Documentation
   • 3.3 External Documentation
4. Unit Testing
   • 4.1 Test Tools & Structure
   • 4.2 Test Coverage Goals
5. JSON Data Handling
   • 5.1 Serialization/Deserialization
   • 5.2 JSON Management
6. Input Handling
7. Performance & Optimization

---

1. Architecture

1.1 MVVM in Unity

• Model: Game data.
• ViewModel: Middle layer (non-MonoBehaviour); handles logic of parsing data and communicates with View.
• View: MonoBehaviour scripts/UI components.

Tips:

• Views only observe and interact via ViewModels.
• Minimize coupling between View and Model.

---

1.2 SOLID Principles

Principle	Unity Example
S - Single Responsibility	A class should have only one reason to change, meaning it should have only one responsibility.
O - Open/Closed	Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This means you should be able to add new functionality without altering existing code.
L - Liskov Substitution	Subtypes should be substitutable for their base types without altering the correctness of the program. In simpler terms, if a class B extends class A, you should be able to use an instance of B wherever you would use an instance of A without breaking anything.
I - Interface Segregation	Clients should not be forced to depend on interfaces they do not use. This means breaking down large interfaces into smaller, more specific ones.
D - Dependency Inversion	High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions. This promotes loose coupling between different parts of the system..

---

1.3 Design Patterns

We actively incorporate common design patterns during design time to improve code clarity, maintainability, and scalability. These patterns are not to be applied blindly but chosen based on context, with the goal of reducing coupling, increasing reusability, and improving testability.

Guidelines:

• During planning or task breakdown, developers should identify opportunities to apply well-known patterns.
• Discuss pattern usage during programming meetings.
• Choose patterns that reduce code duplication and isolate system responsibilities.

Focus:

• Prioritize clean, structured code that separates concerns.
• Avoid overengineering, only apply patterns where they genuinely add value.
• Document where a design pattern is used with a comment or doc summary if it improves clarity for the team.

---

2. Code Style

2.1 Naming Conventions

Item	Style	Example
Classes	PascalCase	EnemySpawner
Methods	PascalCase	TakeDamage()
Variables	camelCase	enemyCount
Constants	ALL_CAPS	MAX_HEALTH
Interfaces	I + PascalCase	IInteractable
Enums	PascalCase	GameState

---

3. Commenting & Documentation

3.1 Comments

Inline

• Use inline comments regularly to clarify complex or non-obvious code logic.
• Use comments to explain why something is done, not just what is done.

Variable Tooltips

• Provide descriptive tooltips or summary comments for every variable, especially public fields or serialized private fields exposed in the Inspector.

3.2 Documentation

• Use triple-slash comments /// to document methods, classes, properties, and interfaces.
• Provide clear summaries describing the purpose and behavior.
• Include descriptions for method parameters, return values, exceptions thrown, and any important remarks or usage notes.

3.3 External Documentation

• Maintain system design documents for major systems and features to provide high-level overviews and architectural decisions.
• These docs should include:
  • System responsibilities and boundaries
  • Key workflows and data flow diagrams
  • Design rationale and chosen patterns
  • Integration points with other systems
  • Known limitations or future improvement areas
• Store design docs in the wiki system design docs section.
• Keep documentation up to date alongside code changes to ensure accuracy and usefulness.

4. Unit Testing

4.1 Test Tools & Structure

• Use the Unity Test Framework (which is NUnit-compatible) for writing and running unit tests.
• Organize tests under the /Assets/Scripts/Tests/ directory within your Unity project to keep them separate from production code.
• Write clear, focused test cases that verify one behavior or scenario per test method.
• Use meaningful test names that describe the expected behavior

4.2 Test Coverage Goals

• Aim to have unit tests covering every function
• Focus on testing behavior and edge cases rather than implementation details.
• Continuously run tests in CI pipelines to catch problems early.

5. JSON Data Handling

5.1 Serialization/Deserialization

• Use Unity's JsonUtility

5.2 JSON Management

• Store all JSON files and related validation resources in the /Assets/JSON/ directory to keep them organized and easily accessible.
• Include a version field in every JSON data object to track evolution.
• Use validation results to provide meaningful error messages or fallback behavior, improving robustness.

6. Input Handling

• Use Unity's Input System Package for flexibility across platforms.
• Abstract input incase a switch is needed.

7. Performance & Optimization

• Pool objects that are created/destroyed frequently (bullets, VFX).
• Avoid FindObjectOfType, GetComponentInChildren, or Resources.Load in Update/loops.
• Minimize per-frame allocations to reduce GC.