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.

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.

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.

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.

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.