comments 5

#11 SwiftLint

Should the opening brace of a function or control flow statement be on a new line or not ?:) This and many other questions cross my mind when I think about coding style. I love the comment from Ray Wenderlich’s Swift style guide:

"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 version and 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
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 😅 :

SwiftLintRun
SwiftLintRun

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
swiftlintYML

You can download the example configuration file from here.

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

SwiftLintRules
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
closingBrace
  • Colon. Colons should be next to the identifier when specifying a type:
colonRule
colonRule
  • Comma Spacing. There should be no space before and one after any comma:
commaRule
commaRule
  • Legacy Constant. Struct-scoped constants are preferred over legacy global constants:
legacy_constant

Very nice article explaining the why.

  • Legacy Constructor. Swift constructors are preferred over legacy convenience functions:
legacy_constructor
  • Opening Brace Spacing. Opening braces should be preceded by a single space and on the same line as the declaration:
opening_brace
  • Statement Position. Else and catch should be on the same line, one space after the previous declaration:
statement_position
  • Trailing Newline. Files should have a single trailing newline:
trailing_newline
  • Trailing Semicolon. Lines should not have trailing semicolons:
trailing_semicolon
  • Trailing Whitespace. Lines should not have trailing whitespace:
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:

Summary

I think that the use of such a tool from the start of the project can be very useful. By setting up together configuration file with considering parameters for each rule, you can be sure that everyone will have to use the same style and for sure it will decrease the amount of bad smells.

For sure I will user this tool in my next project! Hope to hear about your experience with using SwiftLint or similar tools!:) I can’t wait for your comments!

Don’t forget to visit also:

5 Comments

  1. Pablo

    Awesome post series. I just discovered this blog. Congratulations, gentlemen, and keep the good work!

    My linter brain complains that there are two typos in the blogpost. It says ‘SwitLint’ where it should say ‘SwiftLint’, in two different places.

    Thanks for sharing your knowledge and being that simple when explaining things.

    • Bartłomiej Woronin

      Thank you Pablo for yor attention!!! We have just fixed it. It’s great to hear that you enjoy our blog!:) For sure we will still develop our website:)

  2. Akkieee

    That’s an awesome tutorial !!! But what I see, we can only do code analysis using with swift files only using this tool, but how’s about the project which have ObjC files as well as OR would say having bridge file in the project. Is there any code analyser tool available which can work for such projects ?

  3. Sivakumari

    Where should I set swift version for swxftlint, everywhere people are saying swxftlint presences for $XCODE_DEFAULT_TOOLCHAIN_OVERRIDE
    $TOOLCHAIN_DIR
    xcrun -find swift
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain
    /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain
    ~/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain
    ~/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain

    but no help where and how to set.

    Is it in project build phase

Leave a Reply


*