-
Notifications
You must be signed in to change notification settings - Fork 278
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
Feature Request: Customize initialisms or remove "ID" from the common list #41
Comments
We can make the rule configurable. I'd prefer to keep this check under If you have some spare time, it'll be great if you can give it a try! We can discuss the approach you're planning here so we can collect some more thoughts! // cc @chavacava |
As described by @cvbarros, the configuration with an optional (empty by default) white list of "relaxed" initialisms seems the most flexible approach. It may lead to inconsistencies across projects but not more than adding a new rule (option 3). |
I'm thinking of two options:
The second aligns with what you mentioned, and the configuration will be less verbose in case the only initialisms a developer wants to alter is |
I think that |
@cvbarros I won't be able to work on it shortly. Assigned the issue to you so you can take care. |
This PR introduces a white & black lists of initialisms for the `var-naming` rule. Now the rule can be configured with: ```toml [rule.var-naming] arguments = [["ID"], ["VM", "BAR"]] ``` This way, the linter will ignore `customId` but will throw on `customVm` or `customBar`. Fix #41
This PR introduces a white & black lists of initialisms for the `var-naming` rule. Now the rule can be configured with: ```toml [rule.var-naming] arguments = [["ID"], ["VM", "BAR"]] ``` This way, the linter will ignore `customId` but will throw on `customVm` or `customBar`. Fix #41
I implemented this feature right here. Let me know if you have other suggestions. |
This PR introduces a white & black lists of initialisms for the `var-naming` rule. Now the rule can be configured with: ```toml [rule.var-naming] arguments = [["ID"], ["VM", "BAR"]] ``` This way, the linter will ignore `customId` but will throw on `customVm` or `customBar`. Fix #41
Is your feature request related to a problem? Please describe.
In short, I'm looking for alternatives to
golint
, particularly because of this issue:golang/lint#89
Describe the solution you'd like
There are some options to implement this feature.
Id
, in order to name variables such asprojectId
via configuration. This is the most flexible option, but may lead to other initialisms thanId
to be whitelisted, spreading inconsistency across Go projects.ID
completely from the initialism list. The comment on source code, similarly to Golint, states that "Freudian code is rare". However this rule creates warnings for several projects, such as herevar-naming
, so it can be enabled/disabled as whole.Describe alternatives you've considered
I've tried disabling the
var-naming
rule, but other effective idiomatic rules get disabled as well, so that's not an option.Additional context
The lack of flexibility in Golint rules is something that this project can offer, along the speed.
I'd more than happy to give it a try at this myself, if applicable.
The text was updated successfully, but these errors were encountered: