Skip to main content

Overview

The general rule: “use Visual Studio defaults”. Using an IDE that supports the .editorconfig standard makes following these guidelines automatic.
An EditorConfig file (.editorconfig) is provided at the repository root for automatic C# formatting.

Core Principles

Brace Style

Rule 1: Use Allman style braces - each brace begins on a new line.

Single-Line Statement Blocks

Single-line statement blocks can omit braces, but must:
  • Be properly indented on its own line
  • Not be nested in other statement blocks with braces

Indentation and Spacing

Rule 2: Use four spaces for indentation (no tabs).
Rule 7: Avoid more than one empty line at any time. Rule 8: Avoid spurious free spaces.
Good
Bad - spurious spaces
Enable “View White Space” in Visual Studio (Ctrl+R, Ctrl+W) to detect trailing spaces.

Naming Conventions

Fields

Rule 3: Use _camelCase for internal and private fields with readonly where possible.

Visibility Modifiers

Rule 5: Always specify visibility, even if it’s the default. Visibility should be the first modifier.
Correct
Incorrect

Language Features

The this. Keyword

Rule 4: Avoid this. unless absolutely necessary.
Good
Only when needed

The var Keyword

Rule 10: Use var only when the type is explicitly named on the right-hand side.

Target-Typed new()

Rule 10: Target-typed new() can only be used when type is explicitly named on the left-hand side in a definition statement.
Correct
Incorrect

Language Keywords vs BCL Types

Rule 11: Use language keywords instead of BCL types.
Correct
Incorrect

Naming and Documentation

Method Names

Rule 13: Use PascalCasing for all method names, including local functions.

Constants

Rule 12: Use PascalCasing for all constant variables and fields.
Exception: Interop code constants should match the exact name and value of the external API.

nameof() Usage

Rule 14: Use nameof(...) instead of "..." whenever possible.
Good
Avoid

Code Organization

Namespace Imports

Rule 6: Namespace imports should be at the top of the file, outside of namespace declarations.
Correct

Field Placement

Rule 15: Fields should be specified at the top within type declarations.

Control Flow

Single-Statement if

Rule 18: When using a single-statement if:

Labels and goto

Rule 17: When using labels, indent one less than the current indentation.

Special Rules

File-Specific Styles

Rule 9: If a file differs from these guidelines, the existing style in that file takes precedence.

Type Design

Rule 19: Make internal and private types static or sealed unless derivation is required.

XML Documentation

Rule 20: Use XML docs for:
  • Interfaces
  • Classes/methods with sufficient scope or complexity

Magic Numbers

Rule 21: Define magic numbers as named constants.
Good
Avoid
This may be ignored for trivial or syntactically common statements.

Non-ASCII Characters

Rule 16: Use Unicode escape sequences (\uXXXX) instead of literal non-ASCII characters.
Correct
Avoid

Complete Example

From src/Ryujinx.Graphics.Gpu/Shader/ShaderCache.cs:

Enforcement Tools

EditorConfig

The .editorconfig file at the repository root automatically enforces many of these rules in compatible IDEs.

dotnet format

Run before committing:
This tool automatically fixes style violations.
All PRs must pass dotnet format checks in CI. Run this locally before pushing.

IDE Support

Next Steps

PR Guide

Submit your first pull request

Testing

Write unit tests

Building

Build Ryujinx from source