-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Special case id/exceptions for NameFormatViolation #231
Comments
Those are interesting requests. Special casing I have trouble coming up with a nice way to provide "exceptions" via a configuration file. Perhaps an array of exceptions, that's independently regex'd, and violations within those regex match ranges are filtered out? exceptions:
- "(var|let) id:" |
Agreed that special casing sets a dangerous precedent. There's also bound to be others that come up so it would be nicer to have a way for people to set whatever they want. I was thinking more of exceptions for this specific rule rather than a global one, perhaps something like: variable_name_permitted_names:
- id Going a little further, nesting config values would be nice, but I'm sure that's a larger change. Ex: variable_name:
permitted_names:
- id
min_length:
warning: 2
error: 3 |
Same remark for "Variable Name Violation (should start with lowercase)" would be great to have exception like :
cause I know that in Cupertino you can do stuff like :
|
+1 For the config file exception route. |
Thanks to this comment, this is what I came up with:
|
We tend to have properties called
id
on objects and we always get theNameFormatViolation
error because of it. Generally I like this rule but it's annoying when it does it for ID. I'd propose 2 solutions, one temporary, one more permanent.id
so that it won't trigger this violation. It's a pretty common thing I'd assume and I haven't seen anyone take issue with something calledid
before.Thoughts?
The text was updated successfully, but these errors were encountered: