Your Stubborn Coding Style Is Holding the Team Back
The discipline of coding standards in software development teams.
Software engineers can be fanatical about code style. Just ask anyone who's witnessed a tabs-vs-spaces flame war.
However, as teams grow and projects evolve, coding style becomes a key aspect for readability and maintaining consistency in the code bases.
When everybody on a team has a strong opinion and no middle ground is achieved, the team dynamics are affected, and the project delivery suffers.
I experienced it firsthand before.
Around 2014, I worked with a small software engineering team on an iOS app written in Objective-C. I strongly preferred a particular formatting style; everybody was on board.
But later that year, a new proficient iOS developer joined the team, bringing a different code formatting preference to the table.
For the next couple of months, whenever he touched a module I wrote, he reformatted it; whenever I opened a file he edited, I reformatted it.
There was no formal debate—just a low-grade formatting war that wasted hours of developer time and buried useful commits under noise.
Alignment
But I learned from my mistakes.
Whenever I join a new project, I look for the team’s coding standards.
If it’s a greenfield project, it’s usually more straightforward. We have a team sync where we discuss—and debate, most of the time—how we proceed with our code styling:
Indentation and spacing: Tabs vs. spaces, indentation size, line length.
Naming conventions: For variables, functions, classes, and constants (e.g., camelCase vs. snake_case).
Code organization: Logical structure of files, folders, and modules.
Other language features: Like using semicolons, trailing commas, or importing statements.
When the project is already under development and no standards are documented, you will learn about each team member's preferences during code reviews or pair programming.
Sometimes, you will see long discussion threads on a PR on a trivial topic, such as whether the else statement should be on a new line or the same line as the if’s closing bracket.
These are great opportunities for the team to sync and agree on a common direction.
When the team cannot reach an agreement, it helps to have a tech lead or a more senior developer with decision-making authority on the team.
Documentation
After agreeing on the new team’s coding guidelines, the next step is documenting them.
Written coding standards have a couple of benefits:
Smoother Code Reviews and Pair Programming. Shifts discussions from subjective preferences to objective standards, making it easier to focus reviews on logic and architecture rather than formatting.
Time Saving. Reduces the back-and-forth in code reviews, removing the need to refactor for style later since the guidelines are clear upfront.
Promotes Team Ownership. Encourages shared responsibility and mutual respect, giving everyone a chance to contribute to the evolution of coding standards.
Faster Onboarding. New team members can ramp up quickly by reading the style guide, reducing the need for repetitive explanations during code reviews or pairing.
You can think of it as your team’s software development playbook.
There’s no wrong way to document the coding guidelines. However, I like the open-source approach, where I add a CONTRIBUTING.md file in the root folder of the project repository.
This makes it accessible for the entire team to view, reference, and maintain. Each decision can be logged directly into the project repository with a new commit.
If your codebase has more extensive guidelines or your team maintains multiple projects that share the same guidelines, you can create a dedicated document or wiki, such as:
/docs/code-style.mdGithub Wikis
Internal Notion/Confluence pages
Automation
The obvious next step is to remove the coding formatting burden from your team’s shoulders and automate the coding guidelines as much as possible.
For every popular programming language, the open-source community has developed tools that make skipping this step unjustifiable:
Linters. To check the code for stylistic and syntactic errors (e.g., ESLint, Pylint, golint).
Code Formatters. To automatically format code according to your style rules (e.g., Prettier for JavaScript/TypeScript, Black for Python)
Pre-commit Hooks. Run linters and formatters before every commit (e.g., pre-commit, husky).
IDE Integration. Provide editor plugins on top of linters and code formatters so developers see consistent styles while typing.
CI/CD Integration. Add checks to your CI pipeline to fail the build if linting or formatting fails (e.g., GitHub Actions, GitLab CI, CircleCI).
Looking Ahead
There might be yet another reason we should care about consistency in our code bases.
As AI-augmented coding gets better—some would say it’s already too good—and becomes part of our natural development process, code standards are especially valuable because they help steer AI assistants—and your team—toward consistency, clarity, and speed.
—Alex