Otávio Cordeiro

As the name suggests, SwiftLint is a tool used by the Swift community to enforce certain rules, styles, and conventions.

Although I use SwiftLint in my own projects, its real value shows when used in a shared codebase. Code reviews, for instance, are expensive, requiring a lot of back-and-forth between the engineer who submitted the code for review and the reviewers. Quite frequently the suggestions from reviewers are related to coding style and conventions, wasting everyone’s time.

Team opinion should be automated whenever it’s possible, reducing the time wasted in code reviews, leaving the practice for what really matter: logic, performance, code design and architecture.

I first looked into SwiftLint when I caught myself repeating the same feedback in different pull requests. Most of the rules needed by the team were part of SwiftLint already, but some conventions we had were missing. That’s when I decided to contribute to the project, resulting in several new rules and improvements.

Some of the rules I added to the project include:

• anyobject_protocol
  • Prefer using AnyObject over class for class-only protocols
• balanced_xctest_lifecycle
  • Test classes must implement balanced setUp and tearDown methods
• closure_body_length
  • Closure bodies should not span too many lines
• discouraged_assert
  • Prefer assertionFailure() and/or preconditionFailure() over assert(false)
• discouraged_direct_init
  • Discouraged direct initialization of types that can be harmful
• discouraged_optional_boolean
  • Prefer non-optional booleans over optional booleans
• discouraged_optional_collection
  • Prefer empty collection over optional collection
• empty_xctest_method
  • Empty XCTest method should be avoided
• joined_default_parameter
  • Discouraged explicit usage of the default separator
• multiline_parameters
  • Functions and methods parameters should be either on the same line, or one per line
• private_action
  • IBActions should be private
• private_subject
  • Combine Subject should be private
• quick_discouraged_call
  • Discouraged call inside describe and/or context block
• quick_discouraged_focused_test
  • Discouraged focused test. Other tests won’t run while this one is focused
• quick_discouraged_pending_test
  • Discouraged pending test. This test won’t run while it’s marked as pending
• xct_specific_matcher - Prefer specific XCTest matchers over XCTAssertEqual and XCTAssertNotEqual
• xctfail_message
  • An XCTFail call should include a description of the assertion

If I had to pick a favorite rule from the list above, it would be the Multiline Parameter. This was the first rule I implemented and one of the first I enable in a new project.