Wrapping Up

This chapter took a look at code consistency. More than a dry list of dos and don’ts, we focused instead on how to build a process with a series of automated measurements to ensure a lasting, healthy codebase. These techniques and tools are not mandates. Each team must decide which ones to adopt and which to ignore based on experience, code complexity, and the makeup of the team.

We started with coding standards. Elixir’s code formatter enforces a consistent style and the Credo linter helps to measure code quality. We then moved on to types. Typespecs help make your intentions clear and Dialyzer uses them with other clues in the language to find bugs and stylistic inconsistencies. Documentation tools help establish metrics for the health of your system and build more effective documentation.

We spent a good amount of time on tests. Elixir’s testing philosophy is different, with a focus on concurrency and eschewing dynamic mocks and stubs in favor of tools such as Bypass and Mox. Measurement tools such as Coveralls measure coverage as a basic metric for code health and Bureaucrat builds documentation for external interfaces.

All of these concepts build toward better code reviews. Automating these elements led to code reviews that could focus on the application domain rather than tediously pointing out lacking tests, inconsistent style, or imperfect documentation. This was a lot to cover, but we’re ready to stop talking about coding standards and consistency, and start talking about implementation. In the next chapter, we’ll discuss how to integrate with legacy systems and manage your dependencies. You’re almost through Part I.