Naming conventions
Last updated
Last updated
Use _
(underscore) instead of -
(dash) everywhere (in resource names, data source names, variable names, outputs, etc).
Prefer to use lowercase letters and numbers (even though UTF-8 is supported).
Do not repeat resource type in resource name (not partially, nor completely):
Resource name should be named this
if there is no more descriptive and general name available, or if the resource module creates a single resource of this type (eg, in there is a single resource of type aws_nat_gateway
and multiple resources of typeaws_route_table
, so aws_nat_gateway
should be named this
and aws_route_table
should have more descriptive names - like private
, public
, database
).
Always use singular nouns for names.
Use -
inside arguments values and in places where value will be exposed to a human (eg, inside DNS name of RDS instance).
Include argument count
/ for_each
inside resource or data source block as the first argument at the top and separate by newline after it.
Include argument tags,
if supported by resource, as the last real argument, following by depends_on
and lifecycle
, if necessary. All of these should be separated by a single empty line.
When using conditions in an argumentcount
/ for_each
prefer boolean values instead of using length
or other expressions.
resource
count
/ for_each
tags
count
Don't reinvent the wheel in resource modules: use name
, description
, and default
value for variables as defined in the "Argument Reference" section for the resource you are working with.
Support for validation in variables is rather limited (e.g. can't access other variables or do lookups). Plan accordingly because in many cases this feature is useless.
Use the plural form in a variable name when type is list(...)
or map(...)
.
Order keys in a variable block like this: description
, type
, default
, validation
.
Always include description
on all variables even if you think it is obvious (you will need it in the future).
Prefer using simple types (number
, string
, list(...)
, map(...)
, any
) over specific type like object()
unless you need to have strict constraints on each key.
Use specific types like map(map(string))
if all elements of the map have the same type (e.g. string
) or can be converted to it (e.g. number
type can be converted to string
).
Use type any
to disable type validation starting from a certain depth or when multiple types should be supported.
Value {}
is sometimes a map but sometimes an object. Use tomap(...)
to make a map because there is no way to make an object.
Make outputs consistent and understandable outside of its scope (when a user is using a module it should be obvious what type and attribute of the value it returns).
The name of output should describe the property it contains and be less free-form than you would normally want.
Good structure for the name of output looks like {name}_{type}_{attribute}
, where:
{name}
is a resource or data source name
{name}
for data "aws_subnet" "private"
is private
{name}
for resource "aws_vpc_endpoint_policy" "test"
is test
{type}
is a resource or data source type without a provider prefix
{type}
for data "aws_subnet" "private"
is subnet
{type}
for resource "aws_vpc_endpoint_policy" "test"
is vpc_endpoint_policy
{attribute}
is an attribute returned by the output
Always include description
for all outputs even if you think it is obvious.
Avoid setting sensitive
argument unless you fully control usage of this output in all places in all modules.
Prefer try()
(available since Terraform 0.13) over element(concat(...))
(legacy approach for the version before 0.13)
output
Return at most one ID of security group:
When having multiple resources of the same type, this
should be omitted in the name of output:
.
If the output is returning a value with interpolation functions and multiple resources, {name}
and {type}
there should be as generic as possible (this
as prefix should be omitted). .
If the returned value is a list it should have a plural name. .