Konvencija o imenovanjima
Last updated
Last updated
Koristite _
(donja crta) umjesto -
(srednje crte) na svim mjestima (za imena resursa, imena izvora podataka, imena varijabli, izlaznih vrijednosti itd).
Preferirajte upotrebu malih slova i brojeva (iako je UTF-8 podrzan).
Ne ponavaljajte tip resursa u imenima resursa (u dijelovima ili kompletno):
Ime resrusa treba biti imenovano sa this
ako nema neko vise opisujuce ili generalnije ime, ili ako resurs modul kreira jedan resurs tog tipa (npr, u postoji jedan resurs tipa aws_nat_gateway
i vise resursa tipaaws_route_table
, tako bi aws_nat_gateway
trebao biti imenovan this
aaws_route_table
treba da ima bolje opisujuce ime - kao private
, public
, database
).
Uvijek koristite imenice u jednini za imena.
Koristite -
unutar vrijednosti argumenata i na mjestima gdje ce vrijednosti biti izlozene ljudima (npr, unutar DNS imena RDS instance).
Ukljucite argument count
/ for_each
unutar resursa ili blokova izvora podataka kao prvi argument na vrhu i razdvojite novim redom nakon toga.
Ukljucite argument tags,
ako je podrzano od strane resursa, kao zadnji pravi argument pracen sa depends_on
i lifecycle
, ako je neophodno. Sve ovo bi trebalo biti razdvojeno sa jednim praznim redom.
Kada koristite uslove unutar argumentacount
/ for_each
praktikujte booelan vrijednosti (true/false) umjesto koristenjalength
ili drugih izraza.
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 without a provider prefix. {name}
for aws_subnet
is subnet
, foraws_vpc
it is vpc
.
{type}
is a type of a resource sources
{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. .