Sometimes, in a developer’s life, there appears a tool which can significantly facilitate mutual communication. A tool one can use to prevent a burst of anger and uncontrollable rage. One of these lifesavers is this beautiful linter I will briefly introduce to you today.
Swiftlint – Linter for iOS
There are certain situations that can start a war. Even if the parties involved have known each other for years and are generally friends. I am talking about something like this:
To ask whether the first or the second option is correct is to ask time and time again, which came first: the chicken or the egg. Reasonable people will agree on one or the other. But, sometimes there is a rotten apple trying to disturb the well-established convention and push an alternative version into an already functioning code. Such cases bring about a disruption of format and an eruption of panic. The office inhabitants start lighting torches and sharpening their knives. In nine out of ten cases, a verbal agreement will suffice. But what if the intruder of the formatting integrity gets notified in the development environment with the following warning?
In such a case, there is not much left to do but put their tail between their legs and, with tears in their eyes, move the curly brace back where it belongs. The evil is nipped in its very bud and the world is beautiful once again. And what helped us smother the spark of unrest that fast? A very simple and effective tool called Swiftlint.
What is Swiftlint?
Swiftlint is a linter for development on Apple platforms. It is a tool which analyses the source code for code consistency against specified rules. Those can be either in their original state or configured to fit the needs of the team. The styles they are based on are specified in the GitHub’s Swift Style Guide. These styles are reflected in the rules that can be either allowed or ignored. The complete list of rules (including their detailed description) is available in the tool repository, in the file Rules.md. Each rule contains a piece of information on whether it is allowed or ignored in the default state.
Some rules are essential, others less so. It is therefore advisable for a few wise individuals to agree on which should be used and which should not. The last step is creating a file called .swiftlint.yml in the structure of the project, with all the rules agreed on. If the person in charge of the rule definitions enjoys seeing their colleagues’ wailing, they can activate all of the rules. Even the simplest code can then look like this:
And the moral of the story? As the person determining the rules, choose the one not sadistically inclined and is able to communicate without conflict. 😉