# C# Coding Style Rules

These rules define the coding style and conventions I want all my assistants and tools to follow across all projects, not specific to a single solution.

## ✨ General Principles
- Prefer **readability over brevity**.
- Follow **Clean Architecture** and **SOLID principles**.
- Prioritize **maintainability** and **testability** in every layer.

## 🧱 Project Structure
- Organize by **feature/domain**, not by type (e.g., `InvoiceModule` instead of `Controllers/Models/Services`).
- Keep **application logic** separate from **infrastructure**.
- Shared abstractions belong in `Abstractions` or `Contracts`.

## 📐 Code Style
- Use `record` types for immutable data structures (DTOs, Results).
- Use `readonly struct` only where performance is critical and justified.
- Do not abbreviate variable or method names (`userRepository`, not `usrRepo`).
- Use `var` only when the type is obvious from the right-hand side.
- Public members must include XML doc comments.
- Use expression-bodied members only for **simple logic**.

## 🛠 Tooling & Libraries
- Use `Mediator` by @martinothamar for CQRS (no MediatR).
- Use `FluentResults` for error/success handling instead of exceptions.
- Logging via `Serilog`, with all output directed to **Seq**.
- Testing with `NUnit` and `Moq`. Avoid FluentAssertions — use standard NUnit assertions.

## 🔁 Method Conventions
- Keep methods small — ideally under 30 lines.
- Each method should do **one thing only**.
- Favor async/await with `ConfigureAwait(false)` in library code.
- Avoid returning `null`; prefer `Result<T>` or `Option<T>`-like patterns.

## 🔒 Security & Auth
- Auth must flow with the request (e.g., bearer token forwarded).
- Always validate tokens using Microsoft.Identity.Web.
- Do not trust client input — validate all parameters explicitly.

## 🎯 API Design
- Minimal APIs preferred over MVC unless complexity demands otherwise.
- Route by intent or use-case, not controller grouping.
- Return `Results` or `TypedResults<T>` — avoid raw `IActionResult` when not needed.

## 🚀 CI/CD & Build
- All code must build with `dotnet build` and pass `dotnet test`.
- Log enrichment (e.g. userId, correlationId) should be consistent across all logs.
- Every module should have test coverage for both happy and edge cases.

Use Cargo to write a comprehensive suite of unit tests for this function