Using natural language

Example:

list.insert(element, at: index) 

instead of

list.insert(element, position: index)

Naming Factory Methods

Example:

factory.makeObject()

Naming Parameters in Initializers and Factory Methods

Example:

factory.makeObject(key: value)

Instead of:

factory.makeObject(havingProperty: value)

Naming according to side effects

• Functions with side effects (mutating functions) should be named using verbs or nouns prefixed with form- .
• Functions without side effects (nonmutating functions) should be named using nouns or verbs with the suffix -ing or -ed.

print(value)
array.sort()                 // in place sorting
list.add(value)              // mutates list
set.formUnion(anotherSet)    // set is now the union of set and anotherSet

Nonmutating functions:

let sortedArray = array.sorted()     // out of place sorting
let union = set.union(anotherSet)    // union is now the union of set and another set

Boolean functions or variables

Example:

set.isEmpty
line.intersects(anotherLine)

Naming Protocols

• Protocols describing what something is should be named using nouns.
• Protocols describing capabilities should have -able, -ible or -ing as suffix.

Collection        // describes that something is a collection
ProgressReporting // describes that something has the capability of reporting progress
Equatable         // describes that something has the capability of being equal to something

Types and Properties

Example:

let factory = ...
let list = [1, 2, 3, 4]

Avoid Ambiguity

Example:

extension List {
    public mutating func remove(at position: Index) -> Element {
        // implementation
    }
}

The function call to this function will then look like this:

list.remove(at: 42)

This way, ambiguity is avoided. If the function call would be just list.remove(42) it would be unclear, if an Element equal to 42 would be removed or if the Element at Index 42 would be removed.

Avoid Redundancy

A bad example would be:

extension List {
    public mutating func removeElement(element: Element) -> Element? {
        // implementation
    }
}

A call to the function may look like list.removeElement(someObject). The variable someObject already indicates, that an Element is removed. It would be better for the function signature to look like this:

extension List {
    public mutating func remove(_ member: Element) -> Element? {
        // implementation
    }
}

The call to this function looks like this: list.remove(someObject).

Naming variables according to their role

High coupling between Protocol Name and Variable Names

Provide additional details when using weakly typed parameters

func addObserver(_ observer: NSObject, forKeyPath path: String)

to which a call would look like `object.addObserver(self, forKeyPath: path)

instead of

func add(_ observer: NSObject, for keyPath: String)

to which a call would look like object.add(self, for: path)

Types & Protocols

Type and protocol names should start with an uppercase letter.

Example:

protocol Collection {}
struct String {}
class UIView {}
struct Int {}
enum Color {}

Everything else...

Variables, constants, functions and enumeration cases should start with a lowercase letter.

Example:

let greeting = "Hello"
let height = 42.0

enum Color {
    case red
    case green
    case blue
}

func print(_ string: String) {
    ...
}

Camel Case:

All naming should use the appropriate camel case. Upper camel case for type/protocol names and lower camel case for everything else.

Upper Camel Case:

protocol IteratorType { ... }

Lower Camel Case:

let inputView = ...

Abbreviations

Abbreviations should be avoided unless commonly used (e.g. URL, ID). If an abbreviation is used, all letters should have the same case.

Example:

let userID: UserID = ...
let urlString: URLString = ...

Remarks

Swift has an official style guide: Swift.org API Design Guidelines (opens new window). Another popular guide is The Official raywenderlich.com Swift Style Guide. (opens new window)