Hello.
In SwiftLint at version v0.6.0 , I want only variable_name_max_length rule to be enabled.
However, I do not know the settings for latest version.
Is there any method to only the max_length of variable_name rule to be enabled?
.swiftlint.yml file.
# at v0.6.0
disabled_rules:
- force_cast
- force_try
- function_body_length
- line_length
- nesting
- todo
- type_body_length
- type_name
- variable_name
- variable_name_min_length
file_length:
warning: 500
variable_name_max_length:
warning: 45
error: 60
Could you please use lowest threshold?
variable_name:
max_length:
warning: 45
error: 60
min_length:
warning: 1
You can confirm how configuration is interpreted by swiftlint
swiftlint rules --config ~/.swiftlint-test.yml
Loading configuration from '/Users/norio/.swiftlint-test.yml'
+-----------------------------+--------+-------------+------------------------+--------------------------------------------------+
| identifier | opt-in | correctable | enabled in your config | configuration |
+-----------------------------+--------+-------------+------------------------+--------------------------------------------------+
| closing_brace | no | yes | yes | warning |
| colon | no | yes | yes | warning |
| comma | no | yes | yes | warning |
| conditional_binding_cascade | no | no | yes | warning |
| control_statement | no | no | yes | warning |
| custom_rules | no | no | yes | user-defined |
| cyclomatic_complexity | no | no | yes | warning: 10, error: 20 |
| empty_count | yes | no | no | error |
| file_length | no | no | yes | warning: 400, error: 1000 |
| force_cast | no | no | yes | error |
| force_try | no | no | yes | error |
| force_unwrapping | yes | no | no | warning |
| function_body_length | no | no | yes | warning: 40, error: 100 |
| function_parameter_count | no | no | yes | warning: 5, error: 8 |
| leading_whitespace | no | no | yes | warning |
| legacy_constant | no | yes | yes | warning |
| legacy_constructor | no | yes | yes | warning |
| line_length | no | no | yes | warning: 100, error: 200 |
| missing_docs | yes | no | no | warning: public |
| nesting | no | no | yes | warning |
| opening_brace | no | yes | yes | warning |
| operator_whitespace | no | no | yes | warning |
| return_arrow_whitespace | no | no | yes | warning |
| statement_position | no | yes | yes | warning |
| todo | no | no | yes | warning |
| trailing_newline | no | yes | yes | warning |
| trailing_semicolon | no | yes | yes | warning |
| trailing_whitespace | no | yes | yes | warning |
| type_body_length | no | no | yes | warning: 200, error: 350 |
| type_name | no | no | yes | (min_length) w/e: 3/0, (max_length) w/e: 40/1000 |
| valid_docs | no | no | yes | warning |
| variable_name | no | no | yes | (min_length) w: 1, (max_length) w/e: 45/60 |
+-----------------------------+--------+-------------+------------------------+--------------------------------------------------+
I don't want to enable this rule.
Variable names should only contain alphanumeric characters and start with a lowercase character or should only contain capital letters.
Oh, I understand. I thought only about length.
This is enhancement request to variable_name:
Thank you very much for your advice.
This would have been possible before the merging of variable_name_min_length and variable_name_max_length with variable_name. At the time, the justification was that it would be most convenient for users to specify all their variable naming rules in one configuration and avoiding duplication of excluded. Forcing the use of alphanumeric lower case variables is also in line with most Swift style guides. However, if there is enough support for this type of use case, we could consider breaking the rules up again.
@scottrhoyt I'd love to see the alphanumeric rule become optional; we're porting a codebase to use SwiftLint now, and the more granular the rules, the smaller the PRs to do so.
+1
We declare our private properties with an underscore prefix. The length and content rules should be controllable separately.
For some reason this part of the rule just started firing when I converted the code to Swift 3.
Was this eventually done? Another issue with this is some people define Rx Observable using a $ sign at the end. I would want to disable the alphanumeric validation or at least allow specific characters.
If nobody's working on this, I could try adding the configurations mentioned, and open a PR once they're ready 馃檪
Fixed in #1444
Most helpful comment
Oh, I understand. I thought only about length.
This is enhancement request to
variable_name: