The 100% Correct Coding Style Guide
Bill Sourour

Two points, both in general agreement. But I think it does matter. (And, unless you are having the bike shedding conversation over a few cool, frosties, it’s pointless, and I think this is the main point, so: yeah! right on!)

First point: you are part of a team, so act like it.

In almost all companies, teams write software, not people. Teams must agree on a standard and stick to it. Some of it is simple and recent languages assert standards or preferences (e.g. Ruby, Scala have explicit style guides). But after you decide that spaces are better than tabs, the correct number, etc. the team must stick to it. It’s not that any is necessarily better than another, just that once a team picks a style, you become part of the team by embracing the style.

How code looks does matter — good code is more aesthetically appealing than bad — thirty years of reading a lot of code and I can instantly tell something important about a programmer who does not understand this. Well-organized, properly indented code requires acuity, requires a sense of the larger structure and so on. Lines that wrap, methods too long, too many parameter, bad names — all are code smells that are on the fuzzy line of this topic.

Teams must review and work with other team members’ code — having code be stylistically similar reduces the cognitive load on writers and reviewers. The less you have to think about anything unimportant, the more you can think about what your design should be.

Second point, let tools do work so you don’t have to.

I have used a the git-hook approach, but any decent editor will automatically fix up code. IntelliJ and it’s many language-specific flavors is the best for my money (now free, finally!). I just set up my instance with our agreed standards and have it automatically reformat code to clean up before commits. Removes trailing spaces, ensures line endings are right, optimizes imports, adds a newline (or not) to the end of the file, spaces and indents correctly — a thing of beauty.

When new team members don’t have their editors set up correctly, I ruthlessly reject their pull requests until they do! Pendantic? No! The simplest diff in the world is to see that the file has not changed. Making git keep track of unimportant differences is pointless.

Like what you read? Give Tom Harrison Jr a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.