0Pricing
DevOps Bootcamp · Lesson

Code Structure and Naming Conventions

Adopt best practices for organizing your Terraform files and modules, along with consistent naming conventions for resources and variables.

Code Structure and Naming Conventions is a free DevOps Bootcamp lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the DevOps Bootcamp learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Why Structure Terraform Code?

Just like organizing your physical workspace, structuring your Terraform code makes it easier to understand, manage, and collaborate on.

Good structure improves readability, reduces errors, and helps new team members quickly get up to speed.

Essential Terraform Files

Terraform projects usually start with a few key files. Organizing your configuration into these files is a common best practice:

  • main.tf: Defines resources and modules.
  • variables.tf: Declares all input variables.
  • outputs.tf: Defines output values from your infrastructure.
  • versions.tf: Specifies Terraform and provider versions.

Naming Your Resources

Consistent naming makes it easy to identify resources. Follow these general guidelines for the local name (e.g., my_instance in resource "aws_instance" "my_instance"):

  • Use descriptive names: What does the resource do?
  • Use hyphens or underscores: For readability (e.g., web-server-sg or web_server_sg).
  • Avoid generic names: server is less helpful than app-frontend-server.

Terraform local resource names should be unique within a module.

Conventions for Variables

Variables make your configurations flexible. Naming them well is key:

  • Lowercase with underscores: This is the most common convention (e.g., instance_type, vpc_id).
  • Be specific: What does this variable control?
  • Add descriptions: Explain the variable's purpose for clarity.

Good variable names help others understand what inputs your module expects.

Naming Output Values

Outputs expose important information about your deployed infrastructure. Naming them consistently helps consumers:

  • Lowercase with underscores: Similar to variables, e.g., web_server_ip.
  • Descriptive of the value: What information does it provide?
  • Add descriptions: Essential for module outputs to explain what they return.

Example: Simple Configuration

This complete main.tf file demonstrates good naming practices for a resource, variable, and output. You can run terraform init and terraform plan with it.

terraform {
  required_providers {
    null = {
      source = "hashicorp/null"
      version = "~> 3.0"
    }
  }
}

resource "null_resource" "example_web_server" {
  # Descriptive resource name
  triggers = {
    always_run = timestamp()
  }
}

variable "app_environment" {
  description = "The application's deployment environment (e.g., dev, prod)."
  type        = string
  default     = "development"
}

output "resource_unique_id" {
  description = "The unique ID of the example null resource."
  value       = null_resource.example_web_server.id
}

Structuring Terraform Modules

For reusable components, modules have their own clear structure:

  • Root module: The top-level directory containing your main configuration.
  • Child modules: Subdirectories, each containing its own main.tf, variables.tf, outputs.tf, etc.
  • README.md: Essential for explaining the module's purpose, inputs, and outputs.

This keeps modules self-contained and easy to reuse.

Organizing Project Folders

Beyond just files, how you organize your project folders is crucial, especially for larger setups:

  • Separate environments: Have dedicated folders for dev, staging, prod, each with its own configuration.
  • Common modules folder: A modules directory for your custom reusable modules.
  • Root folder for providers: The top-level folder usually defines providers and state backend.

This prevents configuration drift and improves manageability across environments.

Project Folder Example

A typical multi-environment Terraform project might look like this, providing clear separation and reusability:

. ├── modules/ │ ├── vpc/ │ │ ├── main.tf │ │ ├── variables.tf │ │ └── outputs.tf │ └── ec2-instance/ │ ├── main.tf │ └── variables.tf ├── environments/ │ ├── dev/ │ │ └── main.tf │ ├── staging/ │ │ └── main.tf │ └── prod/ │ └── main.tf └── README.md

Check Your Understanding

Which of the following is the best practice for naming a Terraform input variable that specifies the number of instances?

Recap: Structure & Naming

We've learned that well-structured and consistently named Terraform code is vital for readability, maintainability, and team collaboration.

  • Organize files into main.tf, variables.tf, outputs.tf.
  • Use descriptive, lowercase-with-underscores for resources, variables, and outputs.
  • Structure modules and project folders for reusability and environment separation.

These practices lay the groundwork for effective IaC management!

Frequently asked questions

Is the “Code Structure and Naming Conventions” lesson free?

Yes — the full text of “Code Structure and Naming Conventions” is free to read here on the web, and the DevOps Bootcamp course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the DevOps Bootcamp course, upgrade to CoddyKit PRO.

What will I learn in “Code Structure and Naming Conventions”?

Adopt best practices for organizing your Terraform files and modules, along with consistent naming conventions for resources and variables. You practise DevOps Bootcamp with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start DevOps Bootcamp?

No prior experience is required. DevOps Bootcamp on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Code Structure and Naming Conventions” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this DevOps Bootcamp lesson?

Yes. Every DevOps Bootcamp lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Code Structure and Naming Conventions
  2. Version Control with Git
  3. Team Collaboration and Workflows
  4. Documentation and Self-Service Workflows
← Back to DevOps Bootcamp