To Format or Not? 12 Pros and Cons of Using Code a Formatter

If you’ve ever looked over someone else’s code (or your own for that matter), you understand the importance of clean and readable lines. One tool that developers utilize to achieve this is a code formatter.  A formatter automates the arrangement of your code to conform to a specific style guide, giving you some decisions while also keeping everything uniform. You might be on the fence about adding a code formatter to your project, in this post I’ll go over some of the pros and cons of automated code formatters.

Overall, code formatters are highly beneficial and I’d definitely recommend them to anyone that is working on a large project.  I also wrote a guide on how to reformat your javascript codebase with Prettier if this post influences you in any way.  Before getting into the cons, let me go over why you should be using a code formatter.

Pros of Using a Code Formatter

1. Uniform Codebase:  Code formatters ensure a consistent codebase across all contributors.  Once you start to review code in this format and keep things consistent the code quality seems to increase and merge conflicts become easier to deal with.
2. IDE Integration:  Many formatters integrate seamlessly with Integrated Development Environments (IDEs). Users have the flexibility to turn it off within the IDE and even set up a precommit hook to run the format before the merge request is made if particular users don’t are strongly against a formatter.

3. Language-Specific Formatting:  Formatters like Black for Python and Prettier for JS offer opinionated formatting tailored for different languages.   This is beneficial because it can enforce the best and most up to date practices as time goes on.

4. Distinct Role from Linters: You might be thinking, “I already have a linter so why do I need a formatter?” Separating the two allows the linter to focus strictly on rules and the formatter strictly on the style. The integration between formatters and linters is usually clean and there are typically configurations you can set so they don’t interfere with each other.

5. Proactive Bug Catching:  Formatters catch a multitude of potential bugs related to brackets, braces, and semicolons before they become actual problems.  I use this feature to reformat all the time when writing nested components and code.

6. Enhanced Readability:  Formatters make the code easy and clean to read. This translates to more straightforward code reviews and lets you focus on the code logic rather than its appearance.  While it might not seem like much, not having to tab and newline your code manually can save a solid amount of development time.

These are all great reasons to start using a code formatter, but I understand that they also come with downsides.  Below I’ll go over some reasons why you may not want to be using a code formatter on your project.

Cons of Using a Code Formatter

1. Line Break Inconsistencies: I will say, this is the one that has annoyed me the most in my time using a formatter. Depending on the library, lines can be split awkwardly and not all the same if they are close to the line break limit. In the case of Prettier, there are many threads about line breaks and how users would prefer they work differently.  Thankfully, many formatters have some sort of option to ignore lines or certain patterns.

2. Potential Introduction of Bugs: Certain style guides can potentially introduce bugs, for example when reformatting our code base I noticed extra parentheses being added in certain situations. While that didn’t break anything I could see how logic could potentially get altered by that. Another issue I ran into was when an import got removed because it accidentally shared the same name as a variable, this caused our pipeline to silently fail and crashed our app for a few minutes.
   This was not good, but thankfully it did uncover the underlying issue with our variable name being incorrectly named.  So in a way it was helpful! (depending on who you ask)

3. Initial Formatting Can be Cumbersome: The process of reformatting an entire codebase initially can be time-consuming and cumbersome. However, most formatters come with useful tools and commands to either slowly format your code, or to reformat it all at once.  If you’re curious on how I reformatted our entire code base using Prettier – I wrote a guide here.
4. Conflicting Style Opinions: Different team members might have conflicting opinions on the code styling when initially setting things up.  This might be an issue depending on what kind of team you’re working on – but more often than not, sticking to the standard provided by the formatter is a viable resolution.
5. Over-reliance on Automation:  There’s a risk that developers might rely too much on formatters and overlook the importance of learning coding standards and best practices, which are crucial for writing clean and maintainable code manually. 
   
6. Limited Customization: Some developers might find the customization and style options of certain formatters to be limiting. While having opinionated formatters can be helpful, it might not cater to everyone’s preferences, especially if a team has specific and unique coding styles.

Conclusion:

Code formatters have been a game changer for keeping a clean, uniform, and (semi)bug-free codebase.  When I started at a new company that didn’t have formatted code I immediately implemented Prettier – and so far it’s been a hit.  While they do bring along some drawbacks, the pros have definitely outweighed the cons in my experience.

Whether you decide to use a code formatter or not, having an in-depth understanding of the pros and cons can help to make a more informed decision, aligning your coding practices with your developmental goals and team dynamics.  Hopefully after this post you can decide with the team whether or not to leverage code formatters.  Goodluck with your decision and happy coding!

Have any questions, comments or concerns with your code formatting experience? Drop a comment below!