Let the Tools Do Their Job

My Personal Toolbox for Code Consistency and Clean Reviews

This article is part of my code review series. It focuses on one of the most underused productivity boosters: automated checks for style and structure.

In the early days, a lot of reviews included comments on style issues — brace positions, indentation, naming, etc. Today, many tools can take those checks off your hands entirely. In fact, most development environments can apply the changes automatically, so you don’t have to think about them at all.

I mainly work on backend systems in .NET (with Azure), and occasionally on frontend projects using React or Angular. Over time, I’ve developed a small but reliable toolset that helps teams focus reviews on what really matters — behavior, clarity, and architecture — not whitespace or brackets.

Other languages and stacks have their own tooling ecosystems. If you’re in a different environment, ask around in your community to find what’s current and well-supported.

Why Automation Matters in Code Review

Humans are great at understanding intent, structure, and nuance.
Humans are terrible at consistently spotting spacing, naming, formatting, and ordering — especially late in the day or when switching between contexts.

That’s where tools come in.
If a formatter or linter can catch it, you shouldn’t be commenting on it manually. Let tools enforce consistency and free up brainpower for deeper issues.

⚙️ My Core Tools

.editorconfig + dotnet format

I use this for all my .NET projects. .editorconfig itself is platform- and tool-agnostic — it works across multiple languages (including C#, Python, Java, C, etc.) and integrates with a wide range of editors (Visual Studio, VS Code, JetBrains Rider, etc.).
More on .editorconfig

What .editorconfig Does

.editorconfig defines consistent code style rules for your team, such as:

• Indentation
• Spacing
• Naming conventions
• File encoding
• Brackets, casing, newlines, etc.

In .NET, it can also define code-style-specific rules — e.g., preferences for var vs. explicit types, expression-bodied members, etc.

See Microsoft’s guide

How It Integrates with Visual Studio / VS Code

A .editorconfig file on its own defines the rules — it’s your tooling that needs to apply them.

• Visual Studio uses .editorconfig to show suggestions and warnings. It also nudges you via IntelliSense and offers quick fixes via the context menu.
• VS Code supports .editorconfig, but typically requires extensions (like the C# plugin or EditorConfig for VS Code) to apply formatting correctly.

Many .editorconfig rules can also be enforced during build time, depending on their severity setting (suggestion, warning, or error).
Also see: Zero Warnings – Signals, Not Noise

How dotnet format Complements It

dotnet format is a command-line tool that:

• Applies formatting automatically (based on .editorconfig)
• Validates formatting (great for CI)
• Supports fix mode and check mode (for gated builds)

I often add it to CI to ensure consistent formatting without requiring reviewers to point things out manually.

Before committing, simply run:

dotnet format

dotnet format

This checks your code and automatically applies all formatting rules.
It’s especially useful when your team decides to make a broad formatting change — like switching to mandatory braces for single-line if statements. Running dotnet format is faster than making a coffee.

For CI pipelines, use:

dotnet format --verify-no-changes

dotnet format --verify-no-changes

This runs the checks and fails the build if formatting is off — without modifying files.

Roslyn Analyzers + StyleCop

Roslyn analyzers provide static analysis during .NET compilation. They catch issues like:

• Unused variables
• Unsafe patterns
• Common performance traps
• Violations of naming or design guidelines

StyleCop.Analyzers builds on this by enforcing stricter layout, ordering, and documentation rules — especially useful for teams that prefer strong stylistic consistency.

Both can be configured through .editorconfig or ruleset files.

Frontend and Cross-Cutting Tools

ESLint (for JavaScript/TypeScript)

For frontend projects, ESLint (often combined with Prettier) is the de facto standard for static analysis and formatting. It provides similar value to Roslyn analyzers + .editorconfig.

It covers:

• Style and spacing
• Common logic bugs
• Framework-specific rules (e.g., React hooks)
• Type checks (with TypeScript and tsconfig)

It integrates easily into editors and CI setups.

Spectral (for OpenAPI and JSON/YAML)

When working with APIs, I prefer defining the contract (OpenAPI spec) first. It allows both client and server developers to collaborate early — before time is spent on implementation.

Spectral is a linter for OpenAPI, JSON, and YAML that:

• Validates structure
• Enforces naming conventions
• Detects missing metadata (e.g., descriptions, response codes)

I use it to lint OpenAPI documents before merging — especially useful in multi-team or public APIs.

SonarQube / SonarCloud

In larger projects, I almost always recommend including a tool like SonarQube or SonarCloud in the CI pipeline.

Why?

• They catch quality and maintainability issues (many of which StyleCop covers too)
• Each warning comes with an explanation and recommendation
• They track historical trends, including test coverage and code duplication
• They’re updated regularly as coding practices evolve

They do take some time to set up, but the long-term payoff — especially in larger teams — is worth it. I’ve used Sonar’s insights more than once to support technical debt discussions with management.

💡 Conclusion

You don’t need a complex setup. But you do need something.

In my experience, just using .editorconfig and dotnet format already eliminates 90% of the noise in .NET code reviews. Add Roslyn analyzers and ESLint, and most style and structural issues never make it to a human reviewer.

Let the tools do their job — so people can focus on the hard parts.