SwiftLint is a tool to enforce Swift style and conventions. Keeping a codebase consistent and maintainable in a project with a team of developers sometimes may be very hard, different conventions and styles, plus different levels of experience with the language across developers may result in most of the times in an application very difficult to debug and mostly very hard to understand for new developer joining the team.
1. Installation
Simplest way to install SwiftLint is by downloading SwiftLint.pkg from the latest GitHub release and running it. During the installation you may see this alert -
In this case you need to grant an exception for a SwiftLint by clicking the "Open Anyway" button in the General pane of Security & Privacy preferences. This button is available for about an hour after you try to open the app. To open this pane, open System Preferences and click Security & Privacy.
Now you just need to follow the installation instructions. You can also install SwiftLint using Homebrew by running this command:
brew install swiftlint
2. Integrate SwiftLint with Xcode
In order to integrate SwiftLint with Xcode project target to get warnings and errors displayed in the Xcode IDE, you just need to add a new "Run Script Phase" with following script -
if which swiftlint >/dev/null; then
swiftlint
else
echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi
If you don't know how to add a "Run Script Phase" in your project target, here an image for your reference -
3. Test and Configure
In order to test the integration of SwiftLint with your Xcode project target, you just need to build your application and you should have a lot of errors and warnings, mostly if your project has pods installed.
Don't worry, the cool thing is that we can configure what rules to check or not when using Swiftlint. To configure it, all you have to do is create a new file inside your project folder named .swiftlint.yml. Here the general .swiftlint.yml file, which I recommend you to use in your project.
disabled_rules:
- trailing_whitespace
opt_in_rules:
- empty_count
- empty_string
excluded:
- Carthage
- Pods
- SwiftLint/Common/3rdPartyLib
line_length:
warning: 150
error: 200
ignores_function_declarations: true
ignores_comments: true
ignores_urls: true
function_body_length:
warning: 300
error: 500
function_parameter_count:
warning: 6
error: 8
type_body_length:
warning: 300
error: 500
file_length:
warning: 1000
error: 1500
ignore_comment_only_lines: true
cyclomatic_complexity:
warning: 15
error: 25
reporter: "xcode"
Now, Save configuration file and build, you will see that the number of warnings and errors are now so much lower. I recommend you to go to the Swiftlint rules file in their repository and see all of them. Or you can run swiftlint rules command to see all the rules. Also, this will validate your custom .swiftlint.yml file if you run this command in your project directory where .swiftlint.yml file available.
4. Hide Pod Warnings
You can hide Pod warnings from your Xcode Project by adding inhibit_all_warnings! in your Podfile for all 3rd party dependencies or :inhibit_warnings => true for specific dependency.
platform :ios
# ignore all warnings from all dependencies
inhibit_all_warnings!
# ignore warnings from a specific dependency
pod 'FBSDKCoreKit', :inhibit_warnings => true
Then you need to execute pod install.
5. Auto Correct
A cool thing about Swiftlint is that it also can automatically correct certain violations by running the following command on the terminal -
swiftlint autocorrect
Also, Before using the autocorrection feature, Files on disk are overwritten with a corrected version. So, make sure to have backups of these files before running swiftlint autocorrect, otherwise some data may be lost.
6. Configuration Parameters
The following parameters can be configured:
disabled_rules: Disable rules from the default enabled set.
opt_in_rules: Enable rules not from the default set.
whitelist_rules: Acts as a whitelist, only the rules specified in this list will be enabled. Can not be specified alongside disabled_rules or opt_in_rules.
disabled_rules: # rule identifiers to exclude from running
- colon
- comma
- control_statement
opt_in_rules: # some rules are only opt-in
- empty_count
# Find all the available rules by running:
# swiftlint rules
included: # paths to include during linting. `--path` is ignored if present.
- Source
excluded: # paths to ignore during linting. Takes precedence over `included`.
- Carthage
- Pods
- Source/ExcludedFolder
- Source/ExcludedFile.swift
# configurable rules can be customized from this configuration file
# binary rules can set their severity level
force_cast: warning # implicitly
force_try:
severity: warning # explicitly
# rules that have both warning and error levels, can set just the warning level
# implicitly
line_length: 110
# they can set both implicitly with an array
type_body_length:
- 300 # warning
- 400 # error
# or they can set both explicitly
file_length:
warning: 500
error: 1200
# naming rules can set warnings/errors for min_length and max_length
# additionally they can set excluded names
type_name:
min_length: 4 # only warning
max_length: # warning and error
warning: 40
error: 50
excluded: iPhone # excluded via string
identifier_name:
min_length: # only min_length
error: 4 # only error
excluded: # excluded via string array
- id
- URL
- GlobalAPIKey
reporter: "xcode" # reporter type (xcode, json, csv, checkstyle, junit, html, emoji)
You can also use environment variables in your configuration file, by using ${SOME_VARIABLE} in a string.
7. Watch Your Language!
Here the great presentation by JP Simard -
References -
