Skip to content
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

Issues with the Variable and Type Name Rule #191

Closed
kmikael opened this issue Nov 10, 2015 · 2 comments
Closed

Issues with the Variable and Type Name Rule #191

kmikael opened this issue Nov 10, 2015 · 2 comments

Comments

@kmikael
Copy link

kmikael commented Nov 10, 2015

Here are some cases that are correct imho, but are wrongly flagged by this rule, so that me and my team have to disable the variable name rule:

error: Name Format Violation: Variable name should start with a lowercase character: 'URL' (variable_name)

There should be exceptions to this rule like:

  • URLs: var URL: NSURL?
  • Global constants should start with capital letters according to the Cocoa conventions: let ErrorDomain = "…", or for example notification names like let SomethingDidChangeNotification = "SomethingDidChangeNotification"

warning: Name Format Violation: Variable name should be between 3 and 40 characters in length: 'n' (variable_name)

  • Sometimes, short variable names like i and n are appropriate imho, in mathematics contexts or very short closures.
  • Also, when considering Cocoa notification constant names, 40 characters is also pretty restrictive. Here are some examples: PKPassLibraryRemotePaymentPassesDidChangeNotification, NSUndoManagerDidOpenUndoGroupNotification, MPMoviePlayerReadyForDisplayDidChangeNotification and many of the constants own our app are similarly longer and descriptive.

Also I find the 40 character restriction on type names also too limiting considering Cocoa. For example MotorizedVehicleDescriptionCollectionViewCell is totally valid in my opinion.

@kmikael kmikael changed the title Issues with the Variable Name Rule Issues with the Variable and Type Name Rule Nov 10, 2015
@jpsim
Copy link
Collaborator

jpsim commented Nov 10, 2015

I'd welcome PRs addressing any of the concerns you've brought up that you believe should be generally applicable. I'd consider your recommendations for acronym variable names & capitalized global constants to be reasonable.

As for short variable names (i and n) or very long constant names (PKPassLibraryRemotePaymentPassesDidChangeNotification), I'd consider those to not be generally applicable, but rather just exceptions to the rule. For these cases, I'd suggest you temporarily disable the rule around those declarations (using // swiftlint:disable variable_name and // swiftlint:enable variable_name).

@scottrhoyt
Copy link
Contributor

Closing this because #391 provides a workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants