How to do static code analysis in Swift

The subject of static code analyzers has been renamed. The last six months there has been almost no conference without a speech on this issue. But they all talk about analyzers from the inside, show the mechanisms of their work. At the same time, they forget to correctly explain what they were originally intended for. Most often the theoretical part of the work of static analyzers is considered, without practical implementation. Therefore, I will tell you about the goals that are pursued by static analyzers in real teams on commercial projects. And also I will consider an example of the organization of work with various kinds of analyzers in our company.

What is static analysis

This is an analysis of software code, conducted without running it. Therefore, run-time errors of the program cannot be caught with it. Static analysis works only with the text code of the program, which takes a few seconds to run, but saves hours when finding bugs.

There are several methods by which analyzers work.

• Regular expression based search . Everything is very simple here. Find in the code the text that falls under the regular schedule, and you are offered the best option.
• Analysis of the grammar of the language . More complex code parsing. A grammar is represented as a tree, the vertices of which are language operators, and the leaves are operands. Allows you to find much more complex constructions compared to regular expressions. It is more difficult to implement, so most analyzers present the possibility of writing custom rules precisely on the basis of regulars, although inside they can work as a synergy of the first and second. For Swift, at the time of writing, I did not find the possibility of creating a custom rule based on a syntax tree.

Why implement static analysis

Analyzers are needed to find bugs as early as possible. In our case, this is a compilation of the project. The later the bugs are found, the more expensive they will cost the developer and the business as a whole.

However, this goal is too general and does not carry much semantic meaning. Let's try to decompose it into several small ones:

• Finding critical bugs in the code . For example, different force unwrap, where they are not needed. At the same time there are various utilities that allow you to find more complex things, such as circular links.
• Automation of work styleguide . In the commands for the "depersonalization of the code" one of the methods is the introduction of the styleguide, in which the basic practice of writing code is prescribed. Often it turns out a huge document on dozens of pages. Keeping them in my head becomes problematic, especially when a new developer comes to the team who previously wrote in a different style. And it is here that the static analyzer is great. It allows you to automate most of the rules that are written in your styleguide. In languages ​​that appeared before Swift, the styleguide for each rule usually indicates whether it is added to linter. And if added, then under what name. Here is an example for js how to implement it.

How to implement custom rules

The most popular code analyzer for Swift at the moment is swiftlint . We also use tailor . The first allows you to create your own rules based on regular expressions, which makes it possible to implement most of the rules from your styleguide.

Swiftlint allows you to create custom rules that you need to put in the configuration file. Swiftlint.yml, located in your project. The custom language description language has a number of parameters.

• included \ Includes certain files. Works like a regular expression. Example: ". *. Swift". It is optional.
• excluded \ Excludes specific files. Works like a regular expression. Example: ". * Test.swift". It is optional.
• name \ The name of the rule. It is optional.
• regex \ Regular expression to search.
• rule identifier \ Rule identifier. It is optional.
• match_kinds \ The type of code in which the search will take place. There are a lot of them, for example, you can search only in comments or keywords. It is optional.
• message \ Message that is displayed when the regular expression finds this rule.
• severity \ There are two types: warning / error. Depending on the selected value, it will be displayed in Xcode as an error or warning

For example, in your company you use only weak and do not use unowned. The performance of the latter is higher than the first. But the fact that the weak will not lead to the fall of the application is more important for you. This can be easily done using a regular expression and create a custom rule.

unowned: name: "Unowned" regex: 'unowned' message: "Please use `weak` instead. " severity: error 

Another example about comments. Suppose you do not write headers in your project. Regular expression is also perfect for this.

 no_header_comments: name: "Header Comments" regex: '//\s*Created by.*\s*//\s*Copyright' match_kinds: - comment message: "Template header comments should be removed." 

How to implement a code analyzer system

The most interesting part is scaling and automating the process of static analysis . This is especially important if there are several projects and you want all the custom rules to be the same for them. All analyzers have a configuration file in which the settings are stored. There are three such files in our projects: .swiftlint.yml, .tailor.yml, cpd_script.php.
The last file is a script written in php. It starts the analysis of the file produced by the copy-paste detector in the swift project. I will tell about its setup in the following article.

The simplest support option would be to create a separate repository for these files. We do like this . You can connect to the project through submodule . If the settings in the configuration files are updated, it is enough to update the submodule. Then your project will be relevant rules.
In addition, you can use some additional github functions. We use the issues system to create new custom rules or discuss current ones. This makes it possible to understand why a particular rule was rejected. It is convenient to track the status to make changes to the configuration files.
This system works great on CI. It can be configured in such a way that all pull requests in your project could not be smoldered if the analyzers found at least one defect in the code.

Remember to maintain an analysis system.

Static analysis is one of the earliest ways of finding errors in an application. As a result, the cheapest. I hope that the simplest system for storing configuration files of static analyzers will help you to make projects "the same." And still allow you to find more than one bug before the testing phase.