Enforce Swift style and conventions with SwiftLint

“ Hey, I just reviewed your pull request. Excellent. But keep in mind our spacing rule. Oh, and avoid force-casting and force-trying.”

Do you work with a team of multiple developers? If so, I’m sure you’ve come across a situation like the above. the simplest way to maintain clean code and faster code reviews is to enforce coding standards for all developers.

Using different coding styles can lead to confusion and make code less readable. To maintain uniform code styling, it is typical for developers to adopt and adhere to a set of code style rules. However, there may be many rules. It might be challenging to recall all of these guidelines when reviewing one another’s code. This is where SwiftLint comes to the rescue!

SwiftLint

SwiftLint is a free and open-source tool developed by Realm composed of more than 150 rules of different categories, to enforce Swift style and conventions. During the development of new and current projects, we can create different rules based on our coding standards and styles. Swiftlint includes a command-line utility and an Xcode plugin that helps to customize our development environment. It’ll display you warnings and/or errors if you violate these linting rules.

In this article, I’ll show you how to install SwiftLint, configure it, and utilize it throughout the Xcode build process.

1. Get started by Installing

There are many different ways to install SwiftLint on your machine. Check out the link below to see how you want to install it:
https://github.com/realm/SwiftLint#installation

However, the easiest way to install SwiftLint is by downloading SwiftLint.pkg from the latest GitHub release and running it.

2. Let’s configure SwiftLint

Before configuring SwiftLint, we must create a configuration file at the root of our project. The file must be named swiftlint.yml. Linting rules can be added, disabled, or updated in the configuration file. Below is an example of the structure of this file:

You may also read more about the rules at https://github.com/realm/SwiftLint/blob/master/Rules.md.

To run swiftlint as part of the xcode build process, you need to include the swift-lint script in your xcode project. This alerts the developer of any violation that has occurred throughout the development process.

3. Adding to your Xcode project

To add swiftlint to your project, you can add a shell script to the build phases. So go to Project > Build Phases > Press + > New Run Script, and add the below code:

if which swiftlint >/dev/null; then
  swiftlint
else
  echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

Next from the menu select Product > Build.

Xcode will notify the developer of any violations of rules.

Strategy to Quarantine

You will need time to deal with each warning, and you must take your time. Do things well rather than quickly. Because you may not be able to correct everything at once, you will have to do it gradually.

Our goal will be to isolate and exclude infected files, then correct violations of files over time.

1. Hide Pod Warnings / Exclude pods directory

The Pods directory in your project might include libraries or frameworks developed by third-party developers that you wish to skip linting. In such scenarios, you can disable a path or a single file from the linting process in the SwiftLint configuration file.

excluded: # paths to ignore during linting. Takes precedence over `included`.
  - Carthage
  - Pods
  - Source/ExcludedFolder
  - Source/ExcludedFile.swift

You can also hide Pod warnings in your Xcode project by using inhibit_all_warnings! in your Podfile for all third-party dependencies or inhibit warnings => true for individual dependencies.

platform :ios

# ignore all warnings from all pods
inhibit_all_warnings!

# ignore warnings from a specific pod
pod 'FBSDKCoreKit', :inhibit_warnings => true

Then execute pod install

2. Use Auto Correct

If you’re familiar with linting, you might be wondering if SwiftLint supports autocorrect to automatically resolve issues. Yes, but it’s only for a subset of the rules. So, before you start fixing the issues, you may execute the swiftlint autocorrectcommand.

Autocorrect is best for fixing whitespace and indentation issues. If you want to see which rules can be corrected by this feature, run swiftlint rules and see the “correctable” column.

3. Disable the Rules

In some cases, you may want to disable linting on specific lines, pieces of code, or files. Let’s say if you want to fix the issues progressively then you can disable all rules and then re-enable each rule one by one to fix corresponding warnings.

To disable all rules, you can use the following comment syntax:
// swiftlint:disable all

And you can add :previous, :this, or :next keywords to disable SwiftLint for a specific line.

// swiftlint:disable:next force_cast
let noWarning = NSNumber() as! Int
let hasWarning = NSNumber() as! Int
let noWarning2 = NSNumber() as! Int // swiftlint:disable:this force_cast
let noWarning3 = NSNumber() as! Int
// swiftlint:disable:previous force_cas

Note: Disabling any default rule or changing it to our needs is not a good practice because we are breaking the swiftlint coding principles and conventions. So try to avoid disabling the rules unless very much necessary.

Final Thoughts

As developers rotate on to an app, maintaining consistent and clean code becomes a challenge. This post gives an insight of how to solve that challenge locally by utilizing SwiftLint. However, this will not stop developer from committing a faulty code. As to ensure that the code written by all team members is in the right place with linting, you can configure SwiftLint in your Continuous Integration tools.

Writing better code is something we all want to do. With that, I hope that this post has helped you out!

Thanks for reading!