Code Quality

Code quality for your application source code refers to the standards and best practices you follow to write “good code” to help you achieve your business goals. It should help you write software that is easy to maintain, operate and evolve in order to keep you productive.

Why does code quality standards matter so much?

Code that is simple to read and understand is easier to extend, modify and debug

On large projects, code consistency helps you familiarize and be productive faster

You avoid spending time on style and coding standard debates on pull requests

Cross teams contributions and collaborations will be smoother with everyone on the same page

AI assited coding will perform better in an opinionated codebase

It should not be a written collection of best practices

While is is good to document them, a collection of best practices to follow does not scale well

You need to “codify” your best practices and standards in your codebase to make them effective and I will show you how in these sections

Enforcing your code quality standards

Your code quality standards are not effective if they need to be manually reviewed or can easily be broken.

I provide concrete examples in the Code Formatting and Code Linting sections on how to “codify” them.

Development Environment

The first place to start with is to integrate your code quality standards in your Development Environment tools. Typically your project should easily integrate with popular IDEs to automatically standardize your code quality standards such as formatting and linting as well as showing in-context errors.

Continuous Integration (CI)

You should also enforce your code quality standards as part of your Continuous Integration (CI) pipeline. This is important to ensure your main branch stays “clean” and always ready to deploy.

You want to make sure all incoming changes to your main branches are checked. Depending on the size and criticality of your project, you can opt-in to only check changed files. For example, if you are using Github Actions, the Changed Files action makes it easy to do so.

Git Hooks

Using git hooks to enforce your code quality standards is not strictly necessary as your Continuous Integration (CI) will do that.

I will tell you why I think it is still worth it: shorter development feedback loops. You will know sooner when your code changes will not be able to pass the CI and that means you can immediately fix your code without having to switch context.

That’s why I advocate for using git pre-push hook (a hook that is triggered just before you push your branch). You can still have invalid and uninterrupted local commits but as soon as you want to push them to a remote, it’s time to validate them. This can catch for example a file you forgot to format, a misconfigured IDE or a lint error you forgot to address.

Solution: Lefthook

Lefthook is fast and provides a lot of configuration options. It is great both to get started and scale with your project. On the following sections, I show how to configure it for formatting and linting checks.