github.com/kanishk98/terraform@v1.3.0-dev.0.20220917174235-661ca8088a6a/website/docs/language/syntax/style.mdx (about) 1 --- 2 page_title: Style Conventions - Configuration Language 3 description: >- 4 Learn recommended formatting conventions for the Terraform language and a 5 command to automatically enforce them. 6 --- 7 8 # Style Conventions 9 10 The Terraform parser allows you some flexibility in how you lay out the 11 elements in your configuration files, but the Terraform language also has some 12 idiomatic style conventions which we recommend users always follow 13 for consistency between files and modules written by different teams. 14 Automatic source code formatting tools may apply these conventions 15 automatically. 16 17 -> **Note**: You can enforce these conventions automatically by running [`terraform fmt`](/cli/commands/fmt). 18 19 * Indent two spaces for each nesting level. 20 21 * When multiple arguments with single-line values appear on consecutive lines 22 at the same nesting level, align their equals signs: 23 24 ```hcl 25 ami = "abc123" 26 instance_type = "t2.micro" 27 ``` 28 29 * When both arguments and blocks appear together inside a block body, 30 place all of the arguments together at the top and then place nested 31 blocks below them. Use one blank line to separate the arguments from 32 the blocks. 33 34 * Use empty lines to separate logical groups of arguments within a block. 35 36 * For blocks that contain both arguments and "meta-arguments" (as defined by 37 the Terraform language semantics), list meta-arguments first 38 and separate them from other arguments with one blank line. Place 39 meta-argument blocks _last_ and separate them from other blocks with 40 one blank line. 41 42 ```hcl 43 resource "aws_instance" "example" { 44 count = 2 # meta-argument first 45 46 ami = "abc123" 47 instance_type = "t2.micro" 48 49 network_interface { 50 # ... 51 } 52 53 lifecycle { # meta-argument block last 54 create_before_destroy = true 55 } 56 } 57 ``` 58 59 * Top-level blocks should always be separated from one another by one 60 blank line. Nested blocks should also be separated by blank lines, except 61 when grouping together related blocks of the same type (like multiple 62 `provisioner` blocks in a resource). 63 64 * Avoid separating multiple blocks of the same type with other blocks of 65 a different type, unless the block types are defined by semantics to 66 form a family. 67 (For example: `root_block_device`, `ebs_block_device` and 68 `ephemeral_block_device` on `aws_instance` form a family of block types 69 describing AWS block devices, and can therefore be grouped together and 70 mixed.)