Tools for Writing Consistent Code

Web Development

A man leaning over the balcony of a colourfully painted high rise block
A man leaning over the balcony of a colourfully painted high rise block
A man leaning over the balcony of a colourfully painted high rise block

Problems with code

If writing code can be considered hard work, reading other people’s code is even harder. When an application has been written by someone else there will be differences and inconsistencies that make reasoning about the logic of what the code is doing more challenging than it needs to be. As your applications grow beyond the scope of a single developer and start requiring a team, this is a problem that only gets worse. Most lines of code will need to be read and understood by the rest of the team, even if that’s just for a 5-minute review when the code is uploaded to a repo.

Fixing issues with processes

Initially, taking a process-based approach to solving the problem of code consistency so that everyone on the team is writing code that everyone else can work with seems like a great idea. A team chooses a coding style, everyone works to the said style, and what gets developed is delightful. Simple. It can work, particularly if you’re using a language that enforces a style like Python. Usually, it doesn’t.

More often things slip through, the process feels like it takes up too much time, and the whole team realises they’ve not been strictly sticking with the style. Then they have the choice of spending time refactoring to get back in line with the style guide, or they soldier on with a lot of inconsistent code and hope for the best.

A better way

What we use to write code can help with this problem. Modern build tools are incredibly powerful. They not only parse code to find issues but they can actually run the code, find issues, and in some cases even fix problems.

This blog post focuses on the front end of the web build toolchain, but the same applies to backend development and design systems.

Syntax highlighting

The first tool that can help with code development is using an editor that actively helps find problems. At KOMODO, our developers choose what to use, and most of the front end developers have settled on Microsoft’s Visual Studio Code. It’s a fantastic free application that integrates with every part of the development process.

VS Code has syntax highlighters for every conceivable type of file. The obvious types are JavaScript, TypeScript, and PHP, but it doesn’t stop there. There are syntax files available for Dockerfile, Vagrant, Vue, and _everything_ else.

It doesn’t have to stop at simple highlighting though. Plugins like Bracket Pair Colorizer help a developer find mismatched brackets more easily. Indent-rainbow will make following indented code quicker. Finally, Git Lens adds annotations from a project’s git history directly to the editor to make finding changes straightforward.


While these editor plugins help produce better code, they don’t do anything to enforce a code style across a whole team. However, the impressive Prettier plugin and the CLI tool does exactly that. Prettier describes itself as an opinionated code formatter. It takes code and actually modifies it. Single quoted strings in JavaScript become double-quoted. Tab indents become spaces. Commas are stripped from the last elements of arrays. Regardless of what a developer has written, the code that gets saved is consistent across the whole team.

This can take a little getting used to, especially if a team member has strong opinions on what code should look like. However, the important point is that all the code on a project ends up with a consistent style. This means anyone can read it, work with it, and improve it.  The outcome makes for significantly better applications.


However, Prettier can only go so far. To enforce good quality code a team needs to use a linter. Linting finds code that breaks code style rules, which can often improve the application’s speed and find certain classes of bugs. This is a different process to unit testing or integration testing; code that works and passes tests can be still improved by using linting.

ESLint is the industry-standard JavaScript linting tool that can check for various code issues, and understands the latest ES6 and ES7 syntax. It works well with React, Vue, and vanilla JS code, and there are plugins for just about every conceivable build tool. It makes front-end JS code much better.


The last tool to cover is Stylelint. Stylelint is a similar linting tool to ESLint but instead of looking at JavaScript code it looks at SCSS and CSS code (unfortunately it doesn’t do SASS yet). Stylelint as part of a web-pack build chain can block developers adding style rules that use pixel units, force 6 character hex codes, or ban use of the !important operator. There are 150 different rule options, so a team can create a detailed style guide for their code (or stick with the already great default set).

More tools

We’ve listed only a fraction of the tools that are available to developers to improve the quality of what we build daily.

Regardless of what we use, there is one core thread that runs through all of these tools. We shouldn’t spend time and energy working at writing consistent code when a computer is better at that part. The developer’s job is to create code that works elegantly and precisely.

Let the computer deal with formatting it.

Got an idea? Let us know.

Discover how Komodo Digital can turn your concept into reality. Contact us today to explore the possibilities and unleash the potential of your idea.

Sign up to our newsletter

Be the first to hear about our events, industry insights and what’s going on at Komodo. We promise we’ll respect your inbox and only send you stuff we’d actually read ourselves.