Skip to Main content

Coding convention

Backend coding conventions for the Alloy Template project, including editor setup, analyzer enforcement, and shared .editorconfig guidance.

Default coding convention

The backend development team of the Alloy Template project follows a default coding convention defined in the .editorconfig file. This file is based on Microsoft's recommended C# style rules, but with stricter severity levels. For example, if a new const field is created without using Pascal case, the build can report an error instead of only showing a suggestion in the editor.

This approach is intentional, as the Alloy Template project serves as the foundation for future projects, and any inconsistency in coding style may be inherited. Thus, ensuring consistency is crucial.

If you plan to use this template for your project, it is advisable to replace .editorconfig with a less strict version or lower the severity of selected rules. The rules in this template are useful for maintaining consistency, but they can be too strict for day-to-day development in some teams.

Enable the convention in your editor

The .editorconfig file should be the primary source of truth for shared team conventions. Editor support alone is not enough if you also want consistent validation during local builds and in CI. For C# and .NET projects, enable Roslyn analyzers in the project file or in a shared Directory.Build.props file:

<Project>
  <PropertyGroup>
    <EnableNETAnalyzers>true</EnableNETAnalyzers>
    <AnalysisLevel>latest-recommended</AnalysisLevel>
    <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  </PropertyGroup>
</Project>

If your team wants style issues to fail the build, either promote selected rules to error in .editorconfig or enable TreatWarningsAsErrors if that matches your broader warning policy.

VS Code

Use either the official C# Dev Kit extension or the base C# extension from Microsoft. Both rely on Roslyn and respect the repository's .editorconfig rules.

Recommended setup:

  • Install C# Dev Kit and the .NET Install Tool.
  • Open the folder or solution from the repository root so the editor can discover .editorconfig.
  • Verify that the project restores successfully. If restore fails, analyzers and code style diagnostics may be incomplete.
  • Enable format on save if you want automatic whitespace and formatting fixes.
  • Run dotnet format locally or in CI to apply formatting and many style fixes consistently.

Once configured, diagnostics from the analyzer set appear directly in the editor and in the Problems view.

Visual Studio

Visual Studio reads .editorconfig automatically for C# projects, but it is still worth enabling the analysis features that make violations visible during development.

Recommended setup:

  • Open the solution and restore NuGet packages.
  • Enable full solution analysis in Tools > Options > Text Editor > C# > Advanced so diagnostics are not limited to the active file.
  • Keep code style preferences in .editorconfig instead of per-user Visual Studio settings.
  • Configure Code Cleanup to apply formatting and analyzer-backed fixes before commit.
  • Use the Error List during build to catch any rules promoted to warning or error.

If EnforceCodeStyleInBuild is enabled, Visual Studio will also surface those issues during build, which keeps local behavior aligned with CI.

JetBrains Rider

Rider supports .editorconfig well, but you should make sure the IDE uses it as the highest-precedence source for formatting and inspection severity.

Recommended setup:

  • Open the solution from the repository root.
  • Enable support for .editorconfig in Rider settings if it is not already on.
  • Prefer .editorconfig over Rider-specific formatting profiles for shared team rules.
  • Enable inspections while typing and solution-wide analysis so naming and style violations are reported early.
  • Configure cleanup or reformat on save if you want automatic fixes for formatting-related rules.

Rider will then apply the shared naming, formatting, and analyzer severity rules in the same way as other editors, which avoids editor-specific drift.

Regardless of editor choice, the most reliable setup is:

  • Keep shared rules in .editorconfig.
  • Turn on .NET analyzers in the project.
  • Enforce code style during build for rules that matter to the team.
  • Run dotnet format in CI or before merge to catch anything the editor did not fix automatically.

References

General:

VS Code:

Visual Studio:

JetBrains Rider: