# Code Style

This repository follows the local `.editorconfig` and the style visible in the current local changes. Use these notes when creating new code.

## Naming

- Use PascalCase for namespaces, types, methods, properties, enum members, and non-field members.
- Prefix enum type names with `E`, for example `ECellKind`, `EPipeMedium`, `EFailureKind`, and `EEditorTool`.
- Prefix struct type names with `S` when creating new structs.
- Prefix interfaces with `I`.
- Use camelCase for parameters and local variables.
- Prefix private instance fields with `m_` and keep the remainder PascalCase, for example `m_Level` and `m_SelectedTool`.
- Prefix private static fields and static readonly fields with `s_`.
- Prefix constants with `c_`.
- Avoid `this.` unless it is needed for clarity or disambiguation.
- Always use folder-based namespaces when creating types and refactoring.

## Files And Types

- Use file-scoped namespaces.
- Keep one reusable top-level class per file, with the file name matching the class name.
- If a helper type is used only by one class, prefer nesting it inside that class.
- Keep small, cohesive files and extract shared helpers instead of duplicating logic.

## Braces And Blocks

- Use braces for multi-line bodies.
- Omit braces for simple single-line embedded statements when readability stays clear.
- Nested control flow with multi-line bodies should use braces at every multi-line level.
- Keep opening braces on the next line for types, methods, properties, accessors, and control blocks.
- Compact object initializers, switch expressions, and `with` expressions may keep the opening brace on the same line when cleanup formats them that way.

## Blank Lines

- Use a blank line to separate members.
- Use a blank line after control-flow transfer clauses such as `return`, `continue`, `break`, and `throw` when more code follows in the same scope.
- Avoid extra blank lines inside short methods and between tightly related statements.
- Keep at most one blank line in code and declarations.

## Expressions And Formatting

- Prefer `var` when the type is apparent or not useful to repeat; use explicit built-in types such as `int`, `bool`, and `string`.
- Prefer target-typed `new()` when the type is evident.
- Prefer object and collection initializers, including collection expressions such as `[".json"]`.
- Prefer pattern matching for combined checks, for example `cell is { HasPipe: true, Pressure: > 7 }`.
- Prefer switch expressions for simple value selection.
- Prefer expression-bodied properties and accessors when they remain simple.
- Keep simple object initializers and property patterns on one line when they are short and readable.
- Keep long boolean expressions and interpolated status strings readable without introducing unnecessary blank lines.
- Keep using directives outside namespaces.