52 lines
2.9 KiB
Markdown
52 lines
2.9 KiB
Markdown
# 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.
|