Special case id/exceptions for NameFormatViolation

[jakecraige]

We tend to have properties called id on objects and we always get the NameFormatViolation 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.

1. Special case 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 called id before.
2. Add configuration for "exceptions" to this rule and the user could then add "id" to the list of exceptions.

Thoughts?

[jpsim]

Those are interesting requests.

Special casing id makes sense to me, but then again it's a slippery slope and sets a dangerous precedent 😬.

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:"

[jakecraige]

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

[arsonik]

Same remark for "Variable Name Violation (should start with lowercase)" would be great to have exception like :

func test(URL: NSURL) {

}

cause I know that in Cupertino you can do stuff like :

let request = NSURLRequest(URL: url)

[scottrhoyt]

+1 For the config file exception route.

[qalandarov]

Thanks to this comment, this is what I came up with:

identifier_name:
  excluded: # excluded via string array
    - id