Latest

CODESTYLE.md

@@ -1,51 +1,51 @@
-# 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.
-- If nesting a for-loop under another for-loop, always include curly braces in the parent for-loop.
-- 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.
+# 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.
+- If nesting a for-loop under another for-loop, always include curly braces in the parent for-loop.
+- 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.