Andrew Mercer
on this page

Trailing Commas: A Non-Issue Dressed Up as Engineering

There is a certain kind of engineer who, upon encountering a trailing comma at the end of a list in a configuration file, feels a deep and personal offense. This guide is a respectful but firm rebuttal to that instinct — and an argument that organizations which enforce trailing comma style as a serious quality gate are optimizing for the wrong things.

What a Trailing Comma Actually Is

A trailing comma is a comma that follows the last element in a list, map, or block before the closing delimiter. In HCL (HashiCorp Configuration Language, used by Terraform), this is entirely valid syntax:

resource "azurerm_key_vault" "this" {
  name                = "my-keyvault"
  location            = azurerm_resource_group.this.location
  resource_group_name = azurerm_resource_group.this.name,  # trailing comma
}

Terraform parses this without complaint. It has no runtime effect whatsoever. The resulting plan is byte-for-byte identical to the version without the comma. No resource is created differently. No drift occurs. No deployment fails.

The Syntactic Validity Argument

Trailing commas are not a bug in HCL — they are an intentional language design decision. The HCL specification permits them explicitly. The same is true of Rust, Go, Python, JavaScript (ES5+), JSON5, and most modern languages, precisely because they offer a practical benefit: they make diffs cleaner.

When you add an item to a list that already has a trailing comma on its last element, the diff shows one line added. Without the trailing comma, the diff shows two lines changed — the previous last item gains a comma, and the new item is added. The trailing comma version produces less noise in code review.

This is why the Terraform project itself, the AVM (Azure Verified Modules) maintainers, and the HashiCorp provider teams use trailing commas throughout their own codebases — including in the official provider examples distributed with every release. When the people who wrote the tool don't consider it a problem, the case for enforcement becomes difficult to make.

What Linters Are Actually For

Static analysis and linting tools exist to catch things that matter:

  • Security misconfigurations — overly permissive IAM roles, public storage blobs, missing encryption at rest, open security group rules
  • Correctness errors — invalid resource references, missing required arguments, type mismatches, circular dependencies
  • Structural problems — duplicate resource names, missing backend configuration, provider version conflicts
  • Maintainability signals — deprecated resource types, hardcoded credentials, missing variable descriptions

These are the classes of problem that cause incidents, fail audits, create security vulnerabilities, and cost engineering time to debug. A trailing comma causes none of these things. Spending CI minutes and engineering attention enforcing comma placement is a category error — it treats a cosmetic preference as though it were a correctness concern.

Tools like tflint, tfsec, checkov, and terrascan exist for the above. They are worth every minute of configuration effort. A custom trailing comma scanner is a different kind of project entirely.

The Consistency Argument and Its Limits

The most defensible argument for trailing comma enforcement is consistency: if the team has agreed on a style, automated enforcement prevents drift. This is a real consideration. Style consistency does have value — it reduces cognitive load when reading unfamiliar code.

But consistency arguments have a scope. They justify enforcing things that affect readability — variable naming conventions, indentation, file structure, resource naming patterns. They do not automatically justify enforcing every possible stylistic preference, particularly one that:

  1. Has no effect on the tool's output
  2. Is used freely in the upstream codebase the team depends on
  3. Is flagged by a custom linter rather than the canonical formatter

If the goal is style consistency in Terraform, the right tool is terraform fmt. It is maintained by HashiCorp, produces deterministic output, and enforces the canonical HCL style. It does not flag trailing commas as errors — because they are not errors. Running terraform fmt in CI is entirely reasonable. Writing a bespoke tool to enforce a stricter style than terraform fmt requires is an investment that should be justified on its merits.

The Opportunity Cost

Every CI pipeline has a fixed budget of engineer attention. Time spent investigating trailing comma failures is time not spent on:

  • Reviewing the actual resource configuration for security or correctness issues
  • Writing better variable descriptions and module documentation
  • Improving test coverage for infrastructure changes
  • Reducing plan time or state file bloat
  • Onboarding new team members

When a developer submits a Terraform change and the first CI failure they see is a trailing comma warning, one of two things happens: they develop a reflexive annoyance toward the pipeline (which erodes trust in CI as a signal), or they internalize the message that comma placement is what the team cares about. Neither outcome serves the organization.

Broken CI should mean something important is wrong. When it fires on trivialities, the signal degrades.

The Microsoft Endorsement Problem

The Azure Verified Modules program — Microsoft's official, curated library of production-quality Terraform modules for Azure — contains trailing commas throughout its codebase. These are not legacy files that haven't been cleaned up. They are actively maintained, reviewed by Microsoft engineers, and published as the reference implementation for how to write Terraform against Azure resources.

A style policy that flags AVM module examples as non-compliant is, in practical terms, a policy that the upstream authors would fail. That is a reasonable moment to ask whether the policy is calibrated correctly.

What Good Engineering Culture Actually Looks Like

High-performing infrastructure teams tend to focus their automated enforcement on things with clear failure modes, and their human review energy on things that require judgment. Style preferences that have no runtime consequence generally belong in a team style guide — documented, discussed, applied by convention — rather than in a blocking CI gate.

The engineers who have the most impact are not the ones enforcing comma placement. They are solving real problems — reducing toil, improving deployment reliability, shortening feedback loops, hardening security posture, cutting unnecessary cloud spend, and building the kind of infrastructure that lets development teams move fast without breaking things. That work is measurable, visible, and valued. Trailing comma enforcement is none of those things.

A mature codebase has its priorities in order. It runs terraform fmt to keep formatting consistent, tflint to catch structural problems, tfsec or checkov to enforce security policy, and meaningful integration tests to verify behavior. It does not dedicate engineering time to punctuation.

Summary

Concern Does a trailing comma cause it?
Terraform plan changes No
Resource misconfiguration No
Security vulnerability No
Failed deployment No
Diff noise in code review Actually reduced
terraform fmt warning No
Used in official AVM modules Yes, extensively

Trailing commas in HCL are valid syntax, used by upstream maintainers, produce cleaner diffs, and have zero runtime consequence. Enforcing their removal as a quality gate is a choice — but it is a choice that reflects style preference, not engineering judgment. Teams that have made peace with this tend to spend their automation budget on things that actually break.


The irony of building a tool to find trailing commas is not lost on the author. Consider it empirical research.