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

variable_name rule should extend to all identifiers #663

Closed
koke opened this issue May 11, 2016 · 1 comment
Closed

variable_name rule should extend to all identifiers #663

koke opened this issue May 11, 2016 · 1 comment
Labels
rule-request Requests for a new rules.

Comments

@koke
Copy link
Contributor

koke commented May 11, 2016

The Swift API Design Guidelines state that:

Names of types and protocols are UpperCamelCase. Everything else is
lowerCamelCase.

The existing variable_name rule only checks that variables are lowerCamelCase, but other identifiers, like functions or methods aren't checked:

// No error
func Function(param: Int) -> Int {
    return param
}

// error: Variable Name Violation: Variable name should start with a lowercase character: 'Function' (variable_name)
let Function: Int -> Int = { $0 }

I'd propose renaming variable_name to identifier_name and check all the other identifier types as well.

Related: #660

@jpsim jpsim added the rule-request Requests for a new rules. label May 11, 2016
NachoSoto added a commit to NachoSoto/SwiftLint that referenced this issue Jan 4, 2017
…ase in Swift 3

To my surprise, the `type_name` rule is not currently validating this. I've found some issues referring to this (realm#655, realm#654, realm#663, and the change in realm#660),
but it's not clear to me whether not validating this was on purpose.
@ColesyM
Copy link

ColesyM commented Mar 31, 2017

How do we disable the lower case check in config, for now I have had to disable this entire rule :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rule-request Requests for a new rules.
Projects
None yet
Development

No branches or pull requests

3 participants