antonbabenko / terraform-best-practices

Terraform Best Practices free ebook translated into 🇬🇧🇦🇪🇧🇦🇧🇷🇫🇷🇬🇪🇩🇪🇬🇷🇮🇱🇮🇳🇮🇩🇮🇹🇯🇵🇰🇷🇵🇱🇷🇴🇨🇳🇪🇸🇹🇷🇺🇦🇵🇰
https://www.terraform-best-practices.com/
Other
2.07k stars 431 forks source link

Discuss quoting block labels #22

Closed Gowiem closed 4 years ago

Gowiem commented 4 years ago

Is your feature request related to a problem? Please describe.

I'd like the book to discuss putting quotes around block labels. It's not required but they're typically quoted in documentation and the majority of modules. I believe this was cary over from a previous version of HCL that required them, but no longer does.

Terraform fmt and terraform validate do not raise no quotes as an error.

It doesn't seem like these quotes should be necessary and I'd love to see a discussion here or else where on this topic. IMO, the eventual goal should be that labels are no longer being quoted as the norm within the community.

Describe the solution you'd like

I'm referring to no longer quoting resources, modules, or provider "labels" like so:

GOOD

provider aws {
  ...
}

module iam_group_with_policies {
  ...
}

resource aws_waf_ipset whitelist_ipset {
  ...
}

BAD

provider "aws" {
  ...
}

module "iam_group_with_policies" {
  ...
}

resource "aws_waf_ipset" "whitelist_ipset" {
  ...
}
antonbabenko commented 4 years ago

Thanks for asking and opening this issue here.

You are right that they are optional in Terraform, and quotes were always optional in any version of Terraform, actually.

I think that the main reason why quotes are still used are:

  1. Consistency in outer block values (following after keywords "provider", "module", "variable", "output") and inner arguments of the block itself where values were previously required to be quoted, and becoming less required to be quoted in Terraform 0.12
  2. Better separation between values (1 space versus " "). At least for me.
  3. Wrapping - (hyphen, minus) in quotes to prevent math expression evaluation in names. Not so big issue anymore, but still happens sometimes to some people.
  4. HCL <> JSON converters (eg, https://github.com/tmccombs/hcl2json , https://github.com/kvz/json2hcl, etc) won't be doing a good job unquoting values properly.
Gowiem commented 4 years ago

@antonbabenko Ah thanks for the quick response. Thanks for pointing out that it was not tied to a particular version of Terraform -- I had guessed it was, but good to know it just is a community norm.

Those are legitimate arguments against though I feel like they're surmountable problems. What is you personal opinion on the longevity of this practice? Do you think quoting these labels will continue to be the path forward or do you think it will one day fade away?

antonbabenko commented 4 years ago

I personally like to keep them quoted mostly for the reasons of consistency (number 1 in the list above), most of my private code looks 99.9% the same as my code in public repos (styling, naming, patterns, docs...).

I usually see people who are very new to programming and especially tools that advocate "as-code"-principle and big public cloud providers, tend to save 2 bytes by not enquoting these. This is just my observation from some of my training.

Gowiem commented 4 years ago

@antonbabenko gotcha, that's reasonable and I definitely get it. I personally was liking the consistency of the block type not being quoted and the labels not being quoted as well, but I understand that breaks consistency elsewhere.

I'll close out this issue. Seems I'm trying to push an idea that nobody really cares about. You are correct that trying to save 2 bytes to be more terse in syntax is not truly a huge win. Anyway, thanks for the discussion!