Glossary / Code style rules

Code style rules

Code style rules define consistent conventions for formatting and language choices, such as var usage, braces, expression-bodied members, naming, and qualification. In .NET, many style rules are Roslyn diagnostics configurable through .editorconfig; they can be suggestions, warnings, or errors and may offer code fixes.

Configuration and enforcement

Rules can be configured by diagnostic ID or category, with options such as csharp_style_var_*, naming rules, and severity. dotnet format can apply formatting and analyzer fixes according to project configuration. EditorConfig sections can target file patterns, and generated files may have separate treatment. IDE defaults may differ from repository policy unless settings are committed.

Style rules should support readability and maintainability rather than encode personal preferences as failures. Different teams may reasonably choose different styles. Large migrations should be mechanical, isolated, and reviewed separately. Style analyzers are not correctness analyzers; formatting compliance does not establish design quality.

Engineering guidance

Commit shared .editorconfig, pin SDK/analyzer versions, and run dotnet format --verify-no-changes or equivalent in CI where appropriate. Explain exceptions, avoid excessive local suppressions, and keep generated code policy explicit. Adjust rules when they create churn without measurable value.

Interview questions

  1. Where configure C# style? Commonly .editorconfig with Roslyn style options and severities.
  2. What does dotnet format do? Applies or verifies formatting and selected analyzer fixes.
  3. Should every style preference be an error? No; severity should reflect value and legacy burden.
  4. Why isolate mass style changes? To keep functional diffs reviewable.
  5. Does style compliance guarantee maintainability? No; it standardizes conventions but does not ensure good design.

References