1.5.3.1. Code Style Checking

In the Anatomy of Terraform Modules, we introduced a series of specifications regarding Terraform code to ensure code style consistency and adherence to best practices. However, relying solely on manual efforts to ensure that module code and subsequent changes conform to all specifications is clearly unrealistic.

Generally, we handle code style issues using two types of tools: Linters and Autofixers.

1.5.3.1.1. What is a Linter?

A Linter is a static code analysis tool used to check for potential errors, style issues, and deviations from best practices without executing the code. By using a Linter, development teams can:

• Improve Code Quality: Timely detection of syntax errors, potential logic issues, and inconsistent coding styles.
• Unify Coding Standards: Ensure team members follow unified coding standards, reducing disputes during code reviews.
• Reduce Human Errors: Automated checks reduce issues caused by human negligence.

In the Terraform ecosystem, the commonly used Linter tool is TFLint. It is a Linter designed specifically for Terraform, supporting rule plugins for various cloud providers, and is capable of detecting syntax errors, resource configuration issues, and non-compliance with best practices. We will provide an in-depth introduction to it in the subsequent Tools Section.

1.5.3.1.2. What is Autofix?

Autofix refers to the functionality where a tool can automatically repair code issues after detecting them. Compared to Linters that only highlight issues, tools supporting Autofix can:

• Increase Development Efficiency: Automatically fix common issues, reducing the time spent on manual modifications.
• Ensure Style Consistency: Unified automatic repair mechanisms ensure consistent style across the entire codebase.
• Lower Learning Costs: New members can understand and adapt to the team's coding specifications through automatic repairs.

In Terraform, tools supporting Autofix include:

• terraform fmt: Terraform's built-in formatting tool that automatically adjusts code format to comply with the official style guide.
• TFLint: Starting from v0.47.0, TFLint introduced the --fix parameter, supporting the automatic repair of certain detected issues, such as non-standard naming and redundant code.
• avmfix: An automated code repair tool I developed for AVM, which can be used to automatically fix certain issues, such as blocks declared in the wrong files or incorrect argument order.

1.5.3.1.3. Why Distinguish Between Linter and Autofix Tools?

Although Linter and Autofix tools overlap in functionality, their primary focuses differ:

• Linter: Primarily used for detecting issues, providing detailed error messages and improvement suggestions to help developers understand the root cause of the problem.
• Autofix: Focuses on automatically fixing known issues, reducing manual intervention, and improving development efficiency.

Inspired by go fmt, we believe that when managing hundreds or thousands of module code repositories, many choices—including code style—are not something repository maintainers should customize, nor should maintainers spend energy thinking about and deciding on them. Therefore, we should maximize the range of issues covered by automatic repair tools. Human maintainers' energy should be focused on more valuable issues, such as module design, whether input variables are user-friendly, and whether the module is easy to maintain on Day 2.

Another issue is that not all problems can be fixed automatically. For code that we know is problematic but do not know how to fix programmatically, we can only block changes from being merged via the Linter and point out the location of the problem to the change author, leaving it to humans to decide how to fix it.