"You like braces on new lines @elephantronic ? This will strain our friendship!" …hehe, so it really does matter!:)

But coming back to the main subject: This year one of the items on my to do list is a task to learn more about static code analysis tools: linters, Sonar and everything else that can fight against bad smells. In our previous post Maciej mentioned more about code quality and about Codebeat. Today I would like to concentrate on SwitLint, which can help us keep cohesion in our code without straining friendships in our project team:)

SwiftLint checks the source code for programmatic as well as stylistic errors. This is most helpful in identifying some common and uncommon mistakes that are made during coding. SwiftLint is based on guidelines from Swift style guide. Simply saying it can just helps us with:

• maintaining a higher level of code discipline,

• increasing the reliability of the code.

Installation

• using brew:

• or by downloading and installing a fresh release.

Necessary after installation check version using command swiftlint versionand compare it to the latest version available on website.

Running

We have two options:

• just type the following command in the Terminal:

• or we can integrate SwiftLint with Xcode:

RunScript

Just for the test I have run SwiftLint with default options in my current project and I wish I had been using it from the beginning of the project  :

SwiftLint Rules

All available rules which you can use are here.

If you want to have a possibility to control which rule is disabled/enabled and to set thresholds for warnings and errors for a given rule, just create a .swiftlint.yml file in your project directory:

swiftlintYML

You can download the example configuration file from here.

Now by typing in the Terminal swiftlint rules you can check your settings:

SwiftLintRules

Running Options

Sometimes running options can be very useful. Let’s focus on them:

• -- path The path to the file or directory. For example if you want to lint only one file:

• -- config The path to SwiftLint’s configuration file .swiftlint.yml:

• -- use-script-input-files read SCRIPT_INPUT_FILE* environment variables as files. When using this parameter can be useful? For example when we only would like to lint modified files and new files tracked in our github repository. Example of usage which I found here:

• -- quiet flag that prevents status messages like ‘Linting ‘ & ‘Done linting’ from being logged.

• -- reporter generates report with selected format: JSON, Checkstyle, CSV, Xcode. For example:

Autocorrect

Very nice feature of SwiftLint is the auto-correction swiftlint autocorrect, which can automatically fix violations in your code. What type of violations can we fix?

• Closing brace. Closing brace with closing parenthesis should not have any whitespaces in the middle:

closingBrace

• Colon. Colons should be next to the identifier when specifying a type:

colonRule

• Comma Spacing. There should be no space before and one after any comma:

commaRule

• Legacy Constant. Struct-scoped constants are preferred over legacy global constants:

Very nice article explaining the why.

• Legacy Constructor. Swift constructors are preferred over legacy convenience functions:

• Opening Brace Spacing. Opening braces should be preceded by a single space and on the same line as the declaration:

• Statement Position. Else and catch should be on the same line, one space after the previous declaration:

• Trailing Newline. Files should have a single trailing newline:

• Trailing Semicolon. Lines should not have trailing semicolons:

• Trailing Whitespace. Lines should not have trailing whitespace:

Cyclomatic Complexity

In SwiftLint you can find very nice rules, for example:

• File length rule: Files should not span too many lines.
• Function Parameter Count: Number of function parameters should be low.
• Type Body Length: Type bodies should not span too many lines.
• Type Name Rule: Type name should only contain alphanumeric characters, start with an uppercase character and span between 3 and 40 characters in length.

But when I first looked at the rules list my attention was captured by the Cyclomatic Complexity rule. What is this? Wiki says:

"is a software metric (measurement), used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program’s source code."

This parameter just says how complex our functions are. To many ifs are not recommended. If you add 3rd nested if, you should wait a moment and reconsider your solution. This is my weakness, because sometimes I propose really overcomplicated solutions for quite easy problems: it can always be done much simpler… great rule for using by me:) How to add this bodyguard to your config file? Just add it on the end on .swiftlint.yml: