Introduction to Code Consistency
Explore how to establish and maintain code consistency in Elixir through coding standards, testing practices, documentation, reviews, and automation. Understand how these create a structured environment that supports better code quality and reduces technical debt while accommodating team experience levels.
We'll cover the following...
In the past ten years, programmers have made tremendous strides in craftsmanship. Collectively, we’re paying more attention to code structure, testing, types, and more because these concepts matter. New adopters might not have enough experience to completely control every implementation detail, but they can embrace code consistency.
Whether working with a big, mature team or a small, young team, establish a baseline so that the code stays fresh, and the coding stays fun. It’s natural that technical debt accrues more quickly as inexperienced programmers learn the best ways to write code that’s easy to understand and maintain. That’s why code standards are so crucial.
Churn without boundaries is chaotic; churn within a framework is annoying but tolerable.
Components of code quality
In this chapter, we’ll go through code quality. We’ll provide some guidance in five primary areas:
-
Coding standards
The Elixir community has settled on coding standards so code looks the same not just from one module to the next, but also from one project to the next.
-
Types
Testing for functional languages is different. The focus on immutability allows for building shorter, simpler tests.
-
Documentation
For public-facing modules, documentation will help describe what’s happening in the codebase so others will know how to best use the code.
-
Tests
Testing for functional languages is different. The focus on immutability will let you build shorter, simpler tests.
-
Reviews
Fungus grows in the dark. Each different set of eyes is like sunlight into a damp, dark corner, improving quality and adding accountability.
Automations and code consistency
Many of the tools we’ll illustrate are not just guidelines for policing. They are automations. That way, we can continuously get many of these benefits with a fraction of the cost of manual intervention. When we commit to guidelines throughout our organization and as part of your whole lifecycle, from setting expectations when the first developer is hired to maintain the code that’s already in production, there will be profit.
Before we get started, let’s do one bit of housekeeping. A common question might be, “How much is too much?” We don’t have an answer for that. Which tools are installed will depend on the size and experience levels for each team, the size and complexity of the codebase, and the affinity for the approaches we suggest. We’ll offer two pieces of advice:
- We don’t want to implement all of this at once.
- If it feels good, do it more. If it hurts, stop.
None of the authors on this team use all of the tools in this chapter. We all select the best tools for our teams and circumstances. We suggest you do the same.