Why Most .NET Projects Become Messy (And How .editorconfig Fixes It)

Summary: .NET code rules and the role of .editorconfig

Why .NET codebases become “messy” early

• Projects often degrade long before major architecture decisions.
• The early root cause is typically inconsistent code formatting and standards across developers.
• Over time (e.g., ~6 months), this shows up as:
  • PR reviews becoming noisier and more annoying
  • Refactoring becoming riskier
  • Junior developers copying inconsistent patterns

Business impact of style inconsistency

Formatting variance contributes indirectly to:

• Bugs escaping Reviewers get worse signal-to-noise.

• Slower reviews and reduced trust

• Onboarding friction, merge conflicts, and context switching costs

It also creates “burial” effects where Git noise hides real work:

• Formatting-only changes (indentation, whitespace, brace alignment, namespace restructuring) can bury logic changes.

---

Core principle

“Clean code is not written. Clean code is enforced.”

The video frames .editorconfig as an “underrated” system-level mechanism to enforce style.

---

What .editorconfig is

• A repository-level contract: a plain-text .editorconfig file that defines formatting/style rules.
• It’s written so multiple tools (IDEs/formatters/analyzers) can interpret it.
• Once committed to source control, the rules are shared across editors such as:
  • Visual Studio
  • VS Code
  • Rider

---

Important clarification: .editorconfig does not format code by itself

• .editorconfig declares intent, such as:
  • indent size
  • spaces vs tabs
  • file-scoped namespaces preferences
  • brace requirements
• Tooling then applies the intent:
  • Formatters adjust whitespace/layout
  • Roslyn analyzers / IDE diagnostics emit suggestions/warnings/errors (e.g., remove unused using, prefer braces)

---

Demonstrated behaviors

• Formatting demo: changing indent_size affects how code is indented after a cleanup operation.
• Analyzer/severity demo: setting analyzer severity for unused using:
  • none → no underlines/errors/warnings
  • warning / error → entries in the error list and highlighted/underlined issues
• Mentioned that running code cleanup can apply both formatting and analyzer-driven fixes.

---

How the rules are discovered

• Rules are hierarchical, not global:
  1. Search upward from the file’s directory for .editorconfig
  2. Merge settings found along the way
  3. Stop when a .editorconfig with root = true is found (or when reaching the filesystem root)

This allows different areas of a repository to have different rules (useful for mixed codebases).

---

Practical structure and overrides

• Example: keep strict rules for source, but relax them for tests.
• Use a second .editorconfig inside a subdirectory:
  • The child file overrides selected values (e.g., indent_size)
  • It inherits the rest from the parent unless overridden
• You can also exclude generated code directories to prevent noisy churn and meaningless warnings.

---

“Three pillars” for authoring rules

1. Scope Where the rule applies (via section headers), e.g.:

   • all files
   • C# files / C# scripts
   • anything under a folder named generated 2. Value What behavior is desired (e.g., numeric values like indent size, booleans like final newline, namespace style preferences)

2. Severity How strongly the rule is enforced:

   • suggestions → warnings → errors

Proposed change management approach

• Start pragmatic:
  • use high-signal warnings (e.g., unused using)
• Keep controversial rules as suggestions
• Promote stable rules to errors once the team agrees

Rationale: avoids “tool rejection” (developers fighting the tooling / not applying it).

---

Course/product context included in the video

• The video is a free excerpt from a paid course: “pragmatic.net code rules.”
• The full course covers:
  • production-ready rule sets
  • automated cleanup
  • enforcement in teams
  • CI validation
  • Git hooks, and more
• Mentions a pre-sale phase, permanent access after purchase, and a YouTube discount code.

---

Main speakers / sources

• Primary speaker: The course author/instructor (narrator), discussing .editorconfig and Roslyn/Visual Studio behavior.