Skip to content

Code Style Guide and Linting

Daniel Jilg edited this page Oct 4, 2019 · 6 revisions

Linting is happening automatically using swiftlint. The code style guide for this project is whatever swiftlint accepts, so .swiftlint.yml IS the style guide. Proposed changes to the style guide are basically PRs on .swiftlint.yml.

However, there are some optional recommendations:

Documentation

A sentence or two in Swift Doc format about what a public class or function should be used for is very much appreciated.

Private and Public APIs of classes

It is recommended to think about the public and private APIs of classes. Functions and properties that do not concern other entities should be marked private as much as possible.

Private and Public Properties

Properties should be at the top of a class's or struct's definition, with private properties coming after public ones.

// MARK comments in classes

It is recommended to use // MARK style markers in classes to separate concerns in the following order. Ignore marks that are not used by your class.

// MARK: - Properties
// MARK: - Initialization
// MARK: - View Lifecycle
// MARK: - IBActions
// MARK: - Public API
// MARK: - Private API
// MARK: - SomeProtocol

Full Example:

/// A cool class
///
/// More description of what you should use this cool class for.
class MyCoolClass {
    // MARK: - Properties
    var publicProperty: Type
    let publicReadonlyProperty: AnotherType

    private var privateProperty: Type
    private let privateReadonlyProperty: Type

    // MARK: - Initialization
    init(with thing: Thing) {
        self.publicProperty = thing
    }

    // MARK: - View Lifecycle
    override func viewDidLoad() {
        // ...
    }

    override func viewWillAppear() {
        // ...
    }
}

// MARK: - Private API
private extension MyCoolClass {
    // ...
}

// MARK: - SomeProtocol
extension MyCoolClass: SomeProtocol {
    // ...
}