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:

SwiftLint shell script for Xcode build phase

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:

Sample of the configuration file (.swiftlint.yml)

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).

List of SwiftLint rules

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:

command to show the violated rules with number of occurrences

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:

command to show the violated rules

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_identifier

After 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?