You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
kmikael
changed the title
Issues with the Variable Name Rule
Issues with the Variable and Type Name Rule
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).
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:
var URL: NSURL?
let ErrorDomain = "…"
, or for example notification names likelet SomethingDidChangeNotification = "SomethingDidChangeNotification"
warning: Name Format Violation: Variable name should be between 3 and 40 characters in length: 'n' (variable_name)
i
andn
are appropriate imho, in mathematics contexts or very short closures.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.The text was updated successfully, but these errors were encountered: