The Problem
Most developers would rather spend three hours debating tabs versus spaces in a pull request than spend three minutes configuring a tool to just handle it for them.
Without addressing this, every IDE will apply its own conflicting defaults, let alone ensuring the project formats consistently across different operating systems.
Relying on individual editor settings across a diverse technology stack is a guaranteed recipe for noisy Git diffs.
A Continuous Work in Progress
If you try to solve this by manually sharing IDE-specific formatting configurations for Visual Studio, Rider, and VS Code, you will quickly find that the job is never actually finished.
It becomes an endless cycle of tweaking. Someone updates their editor, a new extension changes a default behavior, or a developer switches platforms, and suddenly your perfectly aligned settings are out of sync again.
The Solution
The goal here is simple: make formatting automatic, invisible, and enforced at the repository level.
Instead of dictating specific syntax rules, the focus should be on establishing a baseline agreement. The absolute first step is locking down line endings. Leveraging a .gitattributes file ensures that the classic line-ending battle doesn't just destroy your commit history when crossing operating system boundaries—it prevents your Bash scripts from crashing spectacularly when a Windows-formatted file gets executed on Linux.
From there, establishing universal formatting rules—using something like an .editorconfig file—guarantees that the project dictates the style, rather than the developer's local environment. Finally, tying these rules to automated tooling ensures the standard is upheld without human intervention.
Enforcing the Standard
Even with repository-level rules and automated tooling in place, relying on developers to remember to run the formatter is a losing battle.
The final piece of the puzzle is enforcing these rules right at the boundary: before a commit is even allowed. By utilizing pre-commit hooks, you guarantee that any code failing the formatting check is either automatically fixed or rejected on the spot. This keeps the feedback loop entirely local and prevents unformatted code from ever reaching your CI pipeline.
Final Thoughts
I don't want to push my own degenerate and obscure ideas on how a project should be formatted to satisfy my personal code style fetish. Over the years, I have grown more towards code guidelines rather than a rigid regime.
However, when your team employs tools like SonarQube or similar, you need something in place to ensure some measure of code quality is upheld.
It's hard—but use Galileo:
Measure what can be measured, and make measurable what cannot be measured
Top comments (0)