Have you ever looked at code and felt overwhelmed by the inconsistencies in curly brace placement? Have you felt exhausted trying to follow the inconsistent casing in variable names because your code is maintained by multiple developers with different preferences? Have you found it distracting when code is checked in and not aligned in a readable manner? Formatters can help make your code more consistent and improve code readability.
What is a formatter?
Formatters are used to enforce code styles without changing the runtime behavior. They are used specifically in the layout of your code, looking at styles such as:
- indentation style
- newline placement
- curly brace placement
- parentheses placement
- variable casing
- semicolons
- comments
- order of
usingstatements
Examples of formatters include:
dotnet format(.NET)- Prettier (JavaScript)
- Black (Python)
- Spring Java Format
Why use formatters
Formatters enable you to enforce consistent style throughout your code base. This is especially critical when multiple developers are working in the code and may each have different preferences on code formatting. A shared formatter configuration file can help keep a team of devs consistent across their code.
A benefit of using a code formatter means that you can write the code in your style and let the code formatter clean up your layout when you save your changes. This can happen through webhooks, built into an IDE, or through other extensibility options such as IDE plugins.
The consistency that comes with formatters can also lead to better readability. When there is consistent code layout, it’s easier to notice the exceptions and outliers. Readable code leads to fewer barriers for comprehending code, making it easier to maintain.
Troubles that can arise with formatters
Formatters can help with consistent style throughout code. However, they do have their limitations and pain points as well. They are not tools that analyze for vulnerabilities or performance - formatters are specifically focused on code style. They can be problematic if developers on the same code are using different configurations - though this can be alleviated with a shared configuration file. However, this can lead to some heated conversations if teammates cannot agree on code styles. Formatters may not work for all development teams. They do work well when a team can agree on a code style and trust their tools to help them maintain their style.
How to run formatters
There are many ways to run formatters as part of your development environment. Some options for running formatters include:
- Configure formatters in your IDE
- Configure a formatter command to trigger locally as part of a
pre-commitGit Hook - Run formatting as part of CI/CD
Visual Studio formatting
These are guides for setting up code formatting within Visual Studio:
- Apply Code Styles in Visual Studio
- Automatically reformat Python code in Visual Studio
- Formatting JavaScript in Visual Studio
Visual Studio Code formatting
These are guides for setting code formatting in Visual Studio Code:
- Formatting and linting C# code in Visual Studio Code
- Java formatting and linting
- Black Formatter extension for Visual Studio Code
Other IDEs
These are some other common IDEs and how to work with formatters in them:
- Configure formatting rules in JetBrains Rider (C#)
- Reformat code in IntelliJ (Java)
- Code Assistance in NetBeans (Java)
- Code Formatter preferences in Eclipse (Java)
- Reformat and rearrange code in WebStorm (Web languages, including JavaScript)
- Reformat and rearrange code in PyCharm (Python)
- Editor preferences in PyDev (Python)
Formatters vs linters
When looking into formatting, you may also see the term linter. Linters and formatters go well together at improving consistency throughout your code. Both analyze code and make suggestions to improve it. Where formatters look at style and can make the changes to the format, linters can assist with enforcing style consistency and preventing code that doesn’t meet the consistency from getting checked into a development branch. Linters can also be used for things such as:
- Catch security issues
- Detect bugs
- Find deferencing null issues
- Identify other warning and error situations in code
- Call out code smells
Improve your code in your CI/CD pipeline
We have an on-demand webinar “Real World CI/CD Tips & Tricks to Boost Your App’s Quality” that covers CI/CD pipeline tips. If you want to learn how to incorporate linters in your CI/CD pipeline to boost your code’s readability and maintainability and improve your app’s quality, check the on-demand recording on our YouTube page.