-
Notifications
You must be signed in to change notification settings - Fork 360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add rules to enforce snake_case names #697
Conversation
Hi @jgeurts! Thank you for your contribution. It's so great, but these rules look very similar to existing I think it is better to make these rules into one rule with configurable style options. For instance, What do you think? |
Sounds good! I'm curious to hear your thoughts on the following name/options: Name rule
OptionsArray of configuration options:
|
It sounds good, but I have some suggestions. First, I'm thinking whether this rule should be disabled by default. Styling issues often do not affect the actual Terraform workflow. I believe it is best to minimize the issues that appear by default. Second, the configuration language would be smarter in the following format: rule "terraform_naming_convetion" {
enabled = true
default {
format = "snake_case"
}
resource {
custom {
regex = "^[a-zA-Z_-]{2,}$"
match = true
}
}
} Finally, I have two small concerns:
|
Ah nice, I like that config language alternative! Think we would need the
I’m not sure I understand the first bullet point for an alternative option. Could you explain that a bit more? I’m good to remove options from format. It could go with only snake_case to begin with unless you’d like any others. |
Good suggestion. Your example is cooler than mine 👍
For example, the
This might be good. Unless someone needs another format, minimal implementation would be good. |
Sounds good, I'll work on those changes and will comment back here when I have something to review! |
@wata727 I could use some help, if/when you have some time. This is my first time working with go, so I welcome a strong critique of the code. I'm not familiar with many golang conventions or approaches to keep things concise. The main part I'm struggling with is how to get the tests to recognize my rule configuration. I have a handful of tests stubbed out for Any advice would be appreciated! |
type TerraformNamingConventionRule struct{} | ||
|
||
type terraformNamingConventionRuleConfig struct { | ||
BlockFormatConfig |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
format
and custom
tags are not recognized when embedding a struct. It needs to be modified as follows:
BlockFormatConfig | |
Format string `hcl:"format,optional"` | |
Custom string `hcl:"custom,optional"` |
By the way, embedding of Data
etc. works correctly because the hcl:"data,block"
tag is recognized to the struct itself.
@wata727 Ok, this should be ready for review. Thank you for your help with the changes to this and with my golang programming! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I have left some comments so please take a look :)
@@ -0,0 +1,238 @@ | |||
# terraform_snake_case_data_source_name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The title seems to remain old.
|
||
## How To Fix | ||
|
||
Use lower-case characters and separate words with underscores (`_`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also seems to be old. The way to fix will depend on the rule configuration.
|
||
* `snake_case` - standard snake_case format - all characters must be lower-case, and underscores are allowed. | ||
* `mixed_snake_case` - modified snake_case format - characters may be upper or lower case, and underscores are allowed. | ||
* `""` - empty string - signifies "this selector shall not have its format checked". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[IMO] I guess that making an empty string meaningful is a bit counterintuitive. It would be nice to assign a dedicated word such as "none", what do you think?
|
||
Name | Default | Value | ||
--- | --- | --- | ||
enabled | `true` | Boolean |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
false
?
|
||
// Severity returns the rule severity | ||
func (r *TerraformNamingConventionRule) Severity() string { | ||
return tflint.WARNING |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[IMO] I think that the "notice" is appropriate for violating the naming convention. What do you think?
nameValidator := &NameValidator{ | ||
IsNamedFormat: false, | ||
Format: custom, | ||
Regexp: regexp.MustCompile(custom), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MustCompile
panics if the custom
pattern cannot be parsed.
https://golang.org/pkg/regexp/#MustCompile
nameValidator := &NameValidator{ | ||
IsNamedFormat: true, | ||
Format: format, | ||
Regexp: regexp.MustCompile("^[a-z][a-z0-9]*(_[a-z0-9]+)*$"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can reduce the cost of compiling each time by compiling these pre-defined regexp as package global variables. In this case, it would be good to use MustCompile
.
The rule needs to be added to the providers.go as well: https://github.com/terraform-linters/tflint/blob/master/rules/provider.go#L23 |
# Conflicts: # docs/rules/README.md
} | ||
|
||
// Actually run any checks for modules | ||
if dataNameValidator != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might make sense to move the logic if handling each of the block types into their own methods
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion, I moved the code to separate methods. I'd like to make things a bit more concise, as there's a fair amount of duplication, but I don't think my go abilities & available time allow for that.
Not sure how to kick off the build action again.
|
Rerunned. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! Thank you for a great job!
Adds the following rules:
Please let me know if anything needs changing or if these rules would be more appropriate elsewhere.