This document outlines the coding standards for the Black Tie Cat project. Consistent coding practices improve code readability, maintainability, and reduce the likelihood of bugs.

• Consistency: Write code that follows a uniform style.
• Clarity: Write clear and understandable code.
• Maintainability: Ensure code is easy to maintain and extend.
• Performance: Write efficient and optimized code.

• Folders: PascalCase (e.g., Scripts, Assets).
• Files: PascalCase for scripts (e.g., PlayerController.cs), snake_case for assets (e.g., player_sprite.png).
• Classes: PascalCase (e.g., PlayerController).
• Methods: PascalCase (e.g., MovePlayer).
• Variables: camelCase (e.g., currentHealth).
• Constants: PascalCase (e.g., MaxHealth). Constants should almost never be used. Use them only when a value is truly immutable and shared across multiple files.

• Naming Convention: Use snake_case for Input Map actions.
• Reason: Aligns with Godot's standard conventions and ensures consistency with engine features and documentation.

• move_up
• move_down
• move_left
• move_right
• jump

• Use 1 tab for indentation.
• No trailing whitespaces at the end of lines.
• One blank line between class members for readability.
• One blank line before and after control structures (if, for, while, etc.).
• Space after keywords (e.g., if (condition)).

• Use var for variable declarations when the type is clear from the context.
• Use specific types if it improves code clarity or if var is not recommended by Godot.
• Use descriptive, human-readable, but concise variable and function names.

• Functions should be 10 lines or less. Discuss exceptions with the team.
• Follow DRY (Don't Repeat Yourself) principle: If a function is written in two places, consider refactoring. If used in three or more, it must be refactored.
• Follow YAGNI (You Aren't Gonna Need It): Do not add functionality until it is necessary.

• Comment your code well. Use single-line comments (//) for brief explanations and multi-line comments (/* */) for detailed descriptions.
• Use XML documentation comments (///) for public methods and properties.
• Code should read like a book; aim for self-documenting code with clear, descriptive names and logical structure.

• Use try-catch blocks for error handling.
• Always log exceptions.
• Use specific exceptions rather than the general Exception class.

using Godot;
using System;

public class PlayerController : KinematicBody2D
{
    private const int MaxHealth = 100;
    private int currentHealth;
    private Vector2 velocity;
    
    public override void _Ready()
    {
        currentHealth = MaxHealth;
    }

    public override void _PhysicsProcess(float delta)
    {
        HandleMovement(delta);
    }

    private void HandleMovement(float delta)
    {
        velocity = Vector2.Zero;

        if (Input.IsActionPressed("ui_right"))
        {
            velocity.x += speed;
        }
        if (Input.IsActionPressed("ui_left"))
        {
            velocity.x -= speed;
        }

        velocity = MoveAndSlide(velocity);
    }
}

• Single Responsibility Principle: Each class should have one reason to change.
• Open/Closed Principle: Classes should be open for extension but closed for modification.
• Liskov Substitution Principle: Subclasses should be substitutable for their base classes.
• Interface Segregation Principle: Many client-specific interfaces are better than one general-purpose interface.
• Dependency Inversion Principle: Depend on abstractions, not on concrete implementations.

By following these coding standards, we ensure that our codebase is clean, maintainable, and easy to understand. This will help our team work efficiently and collaboratively.

In Godot C#, it is generally acceptable to use var for variable declarations. However, avoid using var when the type is not immediately clear from the context or when it could reduce code readability. For instance, when working with signals or complex types, specifying the type explicitly can improve understanding and maintainability.

Constants should almost never be used. However, in game design or Godot, constants can be useful when a value is truly immutable and shared across multiple files. Use constants for configuration values that do not change and are used in multiple places to ensure consistency and avoid magic numbers in your code.