SwiftLint in Use
Here I’m going to give you some tips about how to use SwiftLint in existing or new projects with four steps helping you to setup SwiftLint in your projects.
What is SwiftLint?
SwiftLint is a tool that can be used for enforcing Swift style and conventions in projects written in Swift. You can install it in many different ways such as installing in your machine or add it to your CocoaPods repo. Check the following link to see how do you want to install it:
https://github.com/realm/SwiftLint#installation
Adding to your project
After installing the SwiftLint, you can add it to your project by adding a shell script to the build phases. So go to Project > Build Phases > Press + > New Run Script, and add the below code:
Try to have this phase in the very first phases of building the project. If SwiftLint has not been installed correctly you get a warning message, otherwise, it uses the configuration file you mentioned (.swiftlint.yml) and runs the tool. It is now located at the root of your project, in the same folder of your project configuration file (.xcodeproj), although it can be anywhere that you like. But what is this configuration file?
Configuration file, the heart of SwiftLint tuning
In the configuration, file you can add, disable or update the linting rules. You can see a sample of this file’s structure at below:
Don’t worry about it for now! I’m going to explain each bit in more detail in the next sections. Just have this as a reference.
The indentation in this file is important, so have the same indentation as you see in the above sample file.
Some rules are enabled by default. you can disable them in disabled_rules section of your configuration file. There are some other rules which are not activated by default, but you can activate them by adding to opt_in_rules section. To find out about all available rules briefly, type lint rules in the command line (Terminal).
You can also find out about the rules in more detail at the following link:
https://github.com/realm/SwiftLint/blob/master/Rules.md
By following these 4 steps you can gracefully setup SwiftLint in your existing or new projects:
1 — Exclude the code you don’t want to lint
Some codes in your project can be added by third-party libraries that should be skipped in the linting process. In addition, you may borrow some code from an old code base that you don’t want to lint it. In these cases, you can remove a path or a specific file from the linting process in SwiftLint configuration:
One of the good examples is Pods directory which can contain the libraries or frameworks written by third-party developers.
2 — Correct some linting issues automatically!
There is a built-in feature in SwiftLint by which can correct some type of violations automatically. So it is better to first run the related command to solve any issues can be fixed by SwiftLint itself:
swiftlint autocorrect
Just remember to have nothing in your disabled_rules section of configuration file before running this command, rather than those rules will be escaped from correcting.
If you want to see which ruled can be corrected by this feature, run swiftlint rules and see the “correctable” column.
3 — Find rules which are not followed currently
In the next step, we’re going to find out which rules are not followed in your project. To see violated rules run the swiftlint lint by command line in your project directory.
In the output, you can see the rules not followed as warnings such as:
/MyProject/Scenes/MyScene/MyViewController.swift:103:64: warning: Redundant Void Return Violation: Returning Void in a function declaration is redundant. (redundant_void_return)
At the end of each warning, rule identifier is written inside the parentheses (`redundant_void_return` in the example), copy them somewhere until you find all of them.
If your project has a lot of warnings, just run the following command to collect all rules:
At the end of the command, you will find all violated rules with number of occurrences. If you want to see only the list of rules run this command instead:
Add these rules to disabled_rules section for now. If you run the SwiftLint you will find no warnings as you disabled all problematic lint rules in your project.
If you work in a team or want to have neat git history, now it’s time to make your very first commit and create a pull request for SwiftLint works.
4 — Decide about disabled rules
At this stage, you have a list of rules which are violated based on SwiftLint default rules and couldn’t be corrected automatically. When you remove them from your disabled list, you can see the warnings in Xcode.
You have four options here:
a) Correct the lint issue for the rule
If you think the rule is useful for you, you can check the lint issues; resolve them in the entire project and then remove it from the disabled list.
b) Disable the rule generally in the project
If the rule is not suited your project, you can keep it on the disabled list.
c) Disable the rule in specific file or usage
There are times that the rule is useful, but the code base is old and you should change a lot of files which doesn’t worth the time you should spend on. In addition, it’s possible that SwiftLint shows the error where actually no lint error happened (false positive). Moreover, there are times when you prefer to keep that special case breaking the lint rule. In this situation, you can disable the rule in the entire file or just for that special case.
In order to disable it you can use the following comment:// swiftlint:disable rule_identifierAfter this comment to the end of the file, all checking for that rule becomes disabled.
if you want to disable the rule only in the next line of code use the below comment:// swiftlint:disable:next rule_identifier
Likewise, you can disable the rule in the current line and previous line with swiftlint:disable:this and swiftlint:disable:previous respectively.
d) Change the rule setting
Some of the rules have some setting that you can change it in the configuration to adapt your need. For example, you can set the line length in your configuration file as follows:
The above example overrides the default acceptable line_length from 120 to 140 characters. It also changes the error threshold (when SwiftLint stops the project of getting compiled and raises an error) to 160 characters. You can see the list of these configurable rules in the sample configuration file.
Which rule should be resolved first?
You can start with any of the rules and choose any order you like. There is only one point to consider, it is better to resolve line_length, function_body_length, and file_length respectively. The reason is that while you update your project for having the right balance of line length, it probably increases the body of type length and then file length too. Thus, it can make your work double if you do not keep this order for resolving the lint issues.
Now I’m going to add more tips related to using SwiftLint.
Strict mode
If you violate some linting rule, in most cases it raises warnings by default. Practically, there is a possibility that you don’t see the warnings, because they’re being raised after the project built again, not while you write your code! You can change the behaviour to raise errors by adding --strict argument when running the tool. So you can change the SwiftLint script in Xcode to the following one:
By changing the script, you get a build error like the below picture in Xcode next time a rule is being violated:
Enable Xcode auto trim and white-space removal feature
One of the lint rules which can be seen as annoying is trailing_whitespace. By removing whitespaces you stop having extra unused spaces in your files which result in clean commits focused on main changes in your code. The good news is that there is a feature in Xcode that can help you to avoid whitespaces and keep in line with the rule. To enable it, go to preferences > Text Editing > Editing, and tick “Automatically trim trailing whitespace” and “Including whitespace-only lines” options.
Add SwiftLint to CI /CD process
To make sure that the code written by all team members is in the right place with linting, you should setup SwiftLint in your continues integration tools.
Use a style guide with SwiftLint
By using SwiftLint you can keep your code clean at some level by formatting it and enforcing some basic style rules, but it doesn’t ensure you that it follows the desired style until you follow a style guide with and keep an eye on it manually. You can have your own style guide and follow that in your code. Another option is to start using some currently trusted swift style guide and change them with your own needs. Here is a list of some common Swift style guides:
Are there any other tips or ideas that you find it useful while using SwiftLint? Please share them in the comments.
Thank you for reading! If you find it useful please share it via Twitter or LinkedIn to help the others as well.
