Tools for Cleaner Code

The tools we use have a massive impact on the habits we fall into when writing code. When coding, just as in life, we want to gather good habits and avoid bad habits. An example of a good habit would be writing syntactically valid JavaScript. To help us enforce this good habit, we can use a linter to inform us when our code is invalid. We should consider each tool in this way. What good habit does it inspire? What bad habit does it discourage?

If we recall our original tenets of clean code (R.E.M.U) we can observe how various tools help us abide by them. Here's just a small collection of tools that would be of service to the four tenets:

• Reliability: Testing tools, user feedback, error loggers, analytics, linters, static typing tools, and languages
• Efficiency: Performance measurement, analytics, user feedback, UX reviews, ecological costing (for example...

Linters and formatters

A linter is a tool used to analyze code and discover bugs, syntax errors, stylistic inconsistencies, and suspicious constructs. Popular linters for JavaScript include ESLint, JSLint, and JSHint.

Most linters allow us to specify what types of bugs or inconsistencies we would like to look for. ESLint, for example, will allow us to specify a global configuration for a given code base in a root-level .eslintrc (or .eslintrc.json) file. In it, we can specify the version of the language we are using, which features we are using, and which linting rules we would like to be enforced. Here's an example .eslintrc.json file:

{
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
     }
  },
  "extends": "eslint:recommended",
  "...

Static typing

As we've explored at length, JavaScript is a dynamically typed language. If wielded carefully, this can be a great benefit, allowing you to work quickly and permit a level of flexibility in your code that enables colleagues to work with it less painfully. However, there are situations in which dynamic types can create the possibility of bugs and needless cognitive burdens for programmers. Statically typed compiled languages, such as Java or Scala, force the programmer to specify the types they are expecting at the point of declaration (or infer the type by how it is used, prior to execution).

Static typing has the following potential benefits:

• The programmer can have confidence in the types they'll be dealing with, and thus, can make a number of safe assumptions about the capabilities and characteristics of their values, easing development.
• The code can...

E2E testing tools

In the last few chapters, we explored the benefits and types of testing, including an overview of E2E testing. The testing libraries we typically use to build test suites and make assertions rarely include E2E testing facilities, so it's necessary for us to find our own tooling for this.

The aim of an E2E test is to emulate user behavior upon our application and to make assertions about the application's state at various stages of user interaction. Typically, an E2E test will test a specific user flow, such as user can register new account or user can log in and buy product. Whether we're using JavaScript on the server side or the client side, if we're building a web application, it will be hugely beneficial to carry out such testing. To do so, we need to use a tool that can artificially create the user environment. In the...

Automated builds and CI

As we have highlighted, there are a large number of tools available to help us write clean code. These tools can be activated manually, usually via a command-line interface (CLI) or sometimes within our IDEs. Usually, however, it is prudent to have them run as part of our various stages of development. If using source control, then this process will include a commitment or staging process and then a pushing or checking-in process. These events, when combined with the simple act of making changes to files, represent the three vital development stages that our tooling can use to generate their outputs:

• Upon changes to files: It is typical for JavaScript (or CSS) transpilation or compilation to occur at this stage. For example, if you're writing JS that includes the JSX language extension (React), then you're likely relying on Babel to constantly...

Summary

In this chapter, we have discovered the usefulness of tooling, highlighting its power to improve our feedback loops, and how it empowers us to write cleaner code. We have explored a number of specific libraries and utilities as well, giving us a flavor of what types of tools exist and the various ways in which our abilities and habits as programmers can be augmented. We've tried out linters, formatters, static type checkers, and E2E testing tools, and we've seen the merits of tooling at every stage of development.

The next chapter begins our journey into the art and science of collaboration; a vital ingredient for anyone who wants to write clean code. We'll begin with an exploration of how we can write clear and understandable documentation.