Nahuel Zapata
How many times has it happened to you that you were very comfortable coding with your own style, in your own way but, suddenly, your team grew from just you, a single developer becoming a team composed by five others?
Not everyone will be comfortable with the way that you organize your code and your style, because each of us has its own approach. Can you imagine a team of six developers coding without sharing any guidelines? It would be a nightmare codebase! And that’s the special situation when SwiftLint comes to the rescue.
First of all, some definitions
Before digging deeper, let’s go over a few concepts.
- What is a linter/lint?
A linter – or lint – refers to tools that analyze source code to find flag programming or stylistic errors, bugs, and suspicious constructs.
- What is SwiftLint?
SwiftLint is a tool to enforce Swift style and conventions, loosely based on GitHub’s Swift Style Guide. It hooks into Clang and SourceKit to use the AST representation of your source files looking for more accurate results.
Installation
You have many ways to install SwiftLint on your mac, but the most common and simple one is by using Brew:
|
1 2 3 4 5 |
```bash brew install swiftlint ``` |
You can check the documentation if you are not familiarized with Homebrew.
Xcode configuration
Now that we accomplished the installation, it’s necessary to configure our project to run SwiftLint. In order to allow Xcode to run swiftlint command, we have to create a New run script phase on the target’s build phases and paste the following code:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
```bash if which swiftlint >/dev/null; then swiftlint else echo "Warning: SwiftLint is not installed, download it from https://github.com/realm/SwiftLint" fi ``` |
Now you can build (⌘ + B) your project, and be prepared to handle both errors and warnings during compilation. Some errors or warnings, like the shown below.
Warning!
Let me tell you in advance, that in case you use any dependency manager, you will also have errors from the 3rd party libraries we integrated. And this is when you might think “Hell, I don’t need this. I can live without a linter”, but let me tell you: ‘don’t lose your faith’.
You can customize which rules you want to run and how. So let’s configure them.
First of all, you need to be at the same folder level of your Xcode project.
|
1 2 3 4 5 |
```bash vi .swiftlint.yml ``` |
This command will open an empty configuration file for our SwiftLint rules. Note that I use vi for text editing but you can use whatever you want.
Now, you might be wondering what to put in this file. Let me help you with that, by just providing you with a reference file.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
```yaml disabled_rules: - nesting - class_delegate_protocol opt_in_rules: - empty_count - closure_spacing - sorted_imports excluded: - Carthage - Pods force_unwrapping: warning force_cast: warning force_try: severity: warning identifier_name: min_length: 1 max_length: 50 type_name: min_length: 1 max_length: 50 ``` |
Let me explain you a bit about what you just have seen.
– disabled_rules: this key is very self-explanatory, it excludes every rule in our code that we don’t want Xcode to evaluate.
– opt_in_rules: SwiftLint has a set of default rules, that runs without configuring anything. But it also has some optional rules, that by the way, are very interesting, but you have to specify on this file that you want those rules to run on every build command.
– excluded: this key excludes the specified folders, files, etc. But maybe the thing that you may want here is the dependency manager, just because almost all the dependencies aren’t aligned with SwiftLint rules.
– The other lines just configure particular rules. For example the force_cast one is supposed to trigger a warning instead of an error, or the identifier_name key that works for the min and max values.
Sometimes the next magic command will be your best friend. It will help you a lot to avoid repetitive fixing fool errors like trailing or sorting the imports.
|
1 2 3 4 5 |
```bash swiftlint autocorrect ``` |
About SwiftLint
SwiftLint is maintained and funded by Realm Inc. But its code is open source, you can contribute to the project with new rules or bug fixing if you want. You can learn more about SwiftLint by taking a look at this video.
SwiftLint and CI integration
SwiftLint has an integration with Fastlane, another great tool for iOS development and for automating all your deploy process. But if you have a CI server and no Fastlane configured, you can also integrate SwiftLin if your CI server happens to be Jenkins, Travis or Circle.
Conclusion
In my opinion, SwiftLint is a great tool for iOS development, that really helps us to keep our codebase very clean, maintainable and aligned with both our team and the Swift Community.
SwiftLint enforces us to avoid some bad practices like performing a force cast or force unwrapping. It also leads us to learn some language features like it happens in my case with the for where clause.
Triggering example:
Non triggering example:
But not everything is happiness, you will also have to lead its implementation with your team. Some people will be annoyed by having warnings with every single line they write. And that’s up to you. But let me tell you, implementing SwiftLint is worth.
Agustín Palmeira
Daniel Antoriano Takagaki
Ezequiel González
Paula Becchetti
Add comment