I love code formatters
And if you’ll stick around, I’d love to tell you why.
But first, what do you mean?
Yeah, code formatters. What they do is not necessarily obvious but does have a pretty good name, all things considered.
For the purpose of this post, a code formatter, sometimes called an auto formatter, is a program that is run on your code which adjusts the spacing, indentation, or line breaks of the code to match a pre-defined style.
For example, the
go fmt command is a code formatter.
It takes a
.go file or files, and converts the content to match the default Golang style.
It might do something like:
- Replace all spaces-based indentation with tabs.
- Add spaces to line up all types or comments in a single struct definition.
- Reduce any blank lines between code to contain only one blank line.
- Replace any statement ending semicolons (
;) with a line break.
So hopefully that gives you an idea of what I mean when I say “code formatter”.
Seems neat, but why “love”?
There’s apparently an argument that members of an organization will give disproportinate weight to trivial issues. It can be called the law of triviality and within programming is probably more commonly known as bike-shedding. As I think the original supposition goes: If you’re going to build a nuclear reactor, you’re going to spend a lot of time focusing on the color of the bike shed nearby. Mostly because it’s a simple matter that everyone can weigh in on, where as not everyone is going to understand all the necessary details of various parts of a nuclear reactor.
And the reason I love code formatters, is that “proper” code formatting is a super big bike shedding situation.
People (myself included) can argue forever about what random symbol should go where, or how many spaces to use for indentation (or if you should use spaces for indentation at all!), or how many spaces between any random
) and a
: that might be after it.
And honestly, none of that really matters. I think most people can get used to reading code written in most styles, eventually. Whether or not I or they want to do so is a different matter, but it certainly can be done.
So when you have a code formatter, you have to choose the color of the shed once, but then you can automatically enforce that specific color, instead of having it be brought up again and again.
The way they help with that is because you can setup the formatters to run when you save a file in most editors and IDEs. Or you can set them up to run whenever a git commit happens. So the person who is writing the code can usually type it out however they want, but it’ll be saved or committed in a manner consistent with the code formatter.
And a nice side benefit is that, when you’re editing your code, you don’t need to worry a ton about proper spacing. You can simply save the file (if you have the formatter setup to run on save), and then your code is properly formatted and you can keep on typing.
Got any practical information in this post?
Not really but here goes anyway:
If you’re writing Golang, you want
There are some awesome tools out there that’ll help you use it automatically, like vim-go for vim, or vscode-go for visual studio code.
Whatever editor or IDE you prefer, it probably has a go format option.
Also, you should totally turn on
It makes things a lot nicer.
If you’re a python person, I’ve had good luck with autopep8 in the past. Though it’s been quite a while since I’ve used it.
And though I’ve yet to write any, it looks like Rust is trying get a standard autoformatter out there called rustfmt.
I bet if you search around, you can probably find an automatic code formatter for whatever language you’re writing. Which I highly recommend doing, because as I’ve said, I love code formatters.
Happy formatting, y’all :)