Modules Naming Conventions

Loading...

Naming Conventions

When naming modules in your codebase, it is important to follow a consistent naming convention. This will help you and your team understand the purpose of each module and make it easier to navigate the codebase.

Avoid Repeating Resource Type

When naming modules, avoid repeating the resource type in the name. For example, instead of naming a module aws_instance, you can simply name it web_server. This makes the code more readable and avoids redundancy.

• ✅ module "web_server"
• ❌ module "aws_web_server"
• ❌ module "web_server_module"

Use this for Generic Modules:

When naming generic modules, use this as a if the module creates a single resource of this type and it is not necessary to give it a specific name.

• ✅ module "this"
• ❌ module "my_module"
• ❌ module "module"

Exceptions to the Rule!

There are some exceptions to this rule. For example, if you have multiple modules of the same type, you can use a more descriptive name to differentiate between them.

Use Descriptive Names

Use descriptive names for modules to make it clear what the module is used for. For example, instead of naming a module instance, you can name it web_server_instance.

• ✅ module "web_server"
• ✅ module "database_server"
• ❌ module "instance"
• ❌ module "server"

Use Singular Nouns

When naming modules, use singular nouns to make the code more readable and consistent. For example, instead of naming a module web_servers, you can name it web_server.

• ✅ module "web_server"
• ❌ module "web_servers"
• ❌ module "dbs_servers"

Use Lowercase Letters

When naming modules, use lowercase letters and separate words with underscores. This makes the code more readable and consistent.

• ✅ module "web_server"
• ❌ module "Web_Server"
• ❌ module "WebServer"

Use underscores for Multi-word Names

Use underscores to separate words in module names. This makes the code more readable and consistent.

• ✅ module "web_server"
• ❌ module "web-server"
• ❌ module "webServer"

Order of Module Arguments Reference

When naming modules, follow the order of arguments in the module block. This makes it easier to reference the module in other parts of the codebase.

✅ good-example.tf

module "web_server" {
  source = "./path/to/module"

  count = 2

  # ...

  depends_on = [
    aws_instance.web_server
  ]
}

❌ bad-example.tf

module "web_server" {
  count = 2

  source = "./path/to/module"

  # ...

  depends_on = [
    aws_instance.web_server
  ]
}

Use source for External Modules

When using external modules, use the source argument to specify the location of the module. This makes it easier to manage external dependencies and keep the codebase organized.

• ✅ module "web_server" { source = "git@github.com:example/module.git//src/module?ref=v1.0.0" }
• ❌ module "web_server" { source = "https://github.com/example/module.git//src/module?ref=v1.0.0" }
• ❌ module "web_server" { source = "./path/to/module" }