Introduce SwiftLint in a Legacy iOS Codebase
The importance of linter as a static code analysis tool is huge. It will flag stylistic or programming errors, bugs, and suspicious constructs in our codebase. In modern development, it’s quite unimaginable to work without it.
In most cases, when we start some project from scratch, the linter will be introduced at the beginning to encourage the good code style and make PR verifications more comfortable and trustworthy.
But what about a several-year-old codebase? Which has never seen linter in its lifetime. It is never too late to move in the right direction and introduce static code analysis in the project. The question is, what should be the optimal steps? It may be quite overwhelming because the large project could potentially have bazillion warnings and errors for almost any liter rule. In today’s discussion, I’ll try to share several consecutive steps that could be done to make the whole process easier. I will concentrate on the ideas rather than the steps on how to integrate SwiftLint in your project.
1. Disable all opt-in rules
First of all, we want to know all the opt-in rules that swiftlint provides. For that reason, we can open the terminal and write swiftlint rules. Now copy all the opt-in ones and disable them from the beginning. This will prevent Xcode from going crazy and almost killing itself and everybody else around to show all the warnings and errors.
This is a good starting point because the swiftlint was introduced successfully in our Codebase, and now we could move on to spice things up.
2. Autocorractable rules
Now let's find all the autocorrectable rules and remove them from the disabled list. Then run swiftlint autocorrect. Also, my suggestion for those rules would be to set their severity to error. As you imagined, in a large Codebase without linter support, there will be a lot of warnings, so before we go with no warning policy and treat all warnings as errors. We may want to make the linter rules as strict as possible.
So the PR related to these changes will be only included autocorrections, which will be easier to review and approve.
3. Nonautocorractable rules
The approach should be more calculated for those kinds of rules and categorized into two groups: parametric and non-parametric. The rules with parameters should be discussed and decided with all team members. For example, the rules about the variable or file length should be chosen carefully and peacefully.
For each rule, we should create a separate PR. Before making some changes based on the rule requirements, cover them with some tests to be more confident and perform the necessary mutations.
4. Custom rules
After the initial work and predefined rule integration, we could introduce custom rules to reflect on the team's requirements and taste.
The main takeaway is that it’s never too late. We can safely introduce the SwiftLint in our project at a later time. It is important, especially when the project evolves rapidly, with many developers on board. It could go out of hand quickly. SwiftLint will be great enforcement to grow and improve the quality of our project.
