Pathway to cleaner code

Published in

Globant

4 min readJun 28, 2022

With a team of developers, it becomes difficult to have a consistent and maintainable codebase. Due to different experience levels with language and convention style from developer to developer, code becomes hard to understand and maintain.

Here is where swiftlint comes to rescue. It is a tool to enforce swift style and conventions which results in a codebase that is more manageable, readable and understandable.

SwiftLint is based on guidelines from the Swift style guide.

So basically it help us with:

maintaining a higher level of code discipline
increasing the code’s reliability

Rules:

SwiftLint enforces the style guide rules that are generally accepted by the Swift community. There are over 200 rules included in swift lint. Rules list and their information can be found here.

Rule inclusion:

disabled_rules: Disable rules from the default enabled set(e.g. -colon, -comma, -control_statement)
opt_in_rules: They are disabled by default (i.e., you have to explicitly enable them in your configuration file). Guidelines on when to mark a rule as opt-in:
A rule that can have many false positives (e.g. empty_count)
A rule that is too slow
A rule that is not general consensus or is only useful in some cases (e.g. force_unwrapping)
only_rules: Only the rules specified in this list will be enabled. Cannot be specified alongside disabled_rules or opt_in_rules.
analyzer_rules: This is an entirely separate list of rules that are only run by the analyze command. All analyzer rules are opt-in, so this is the only configurable rule list; there are no equivalents for disabled_rules only_rules.
custom_rules: Custom regex-based rules can be defined in the configuration file. If using custom rules in combination with only_rules, make sure to add custom_rules as an item under only_rules.
Disable rule inline:

* Rules can be disabled with a comment inside a source file with the following format:

swiftlint:disable <rule1> [<rule2> <rule3>…]

*The rules will be disabled until the end of the file or until the linter sees a matching enable comment:

swiftlint:enable <rule1> [<rule2> <rule3>…]

Example

Including the all keyword will disable all rules until the linter sees a matching enable comment

swiftlint:disable all

swiftlint:enable all

Example:

It’s also possible to modify a disable or enable command by appending :previous, :this or :next for only applying the command to the previous, this (current) or next line respectively.

Example:

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. Like:

To get complete insights on rules please visit here.

Errors/Warnings:

An example of how the error/warning looks like Xcode:

Cool things about swiftlint:

Multiple configuration files: There are some instances where it’s required to have a project level configuration while allowing overrides in each project via child configuration. This can be easily achieved by adding multiple configuration files. These files are merged and combined in one configuration which is then applied as a single configuration file.

2. Auto correct: Swift lint can automatically correct certain violation by running command: swiftlint autocorrect

Note: This command overwrites the files on disc with the corrected version, so make sure to take backup of files before running this command.

3. You can also use environment variables in your configuration file, by using ${SOME_VARIABLE} in a string.

Installation:

Using Homebrew: brew install swiftlint
Using CocoaPods: pod ‘SwiftLint’ simply add this to your Podfile
Using Mint: $ mint install realm/SwiftLint
Using a pre-built package: Install SwiftLint by downloading SwiftLint.pkg from the latest GitHub release and run it.
Installing from source: Build and install from source by cloning the project from here and run “make install” (Xcode 13 or later).