Omega Swift Style Guide

Goals

Following this style guide should:

• Make it easier to read and begin understanding unfamiliar code.
• Make code easier to maintain.
• Reduce simple programmer errors.
• Reduce cognitive load while coding.
• Keep discussions on diffs focused on the code's logic rather than its style.

Note that brevity is not a primary goal. Code should be made more concise only if other good code qualities (such as readability, simplicity, and clarity) remain equal or are improved.

Guiding Tenets

• This guide is in addition to the official Swift API Design Guidelines. These rules should not contradict that document.
• These rules should not fight Xcode's ^ + I indentation behavior.
• We strive to make every rule lintable:
  • If a rule changes the format of the code, it needs to be able to be reformatted automatically (either using SwiftLint autocorrect or SwiftFormat).
  • For rules that don't directly change the format of the code, we should have a lint rule that throws a warning.
  • Exceptions to these rules should be rare and heavily justified.

Table of Contents

1. Xcode Formatting
2. Naming
3. Style
   1. Functions
   2. Closures
   3. Operators
4. Patterns
5. File Organization
6. Objective-C Interoperability
7. Contributors
8. Amendments

Xcode Formatting

You can enable the following settings in Xcode by running this script, e.g. as part of a "Run Script" build phase.

• (link) Each line should have a maximum column width of 100 characters.

  Why?

  Due to larger screen sizes, we have opted to choose a page guide greater than 80.

  We currently only "strictly enforce" (lint / auto-format) a maximum column width of 130 characters to limit the cases where manual clean up is required for reformatted lines that fall slightly above the threshold.

• (link) Use 4 spaces to indent lines.

• (link) Trim trailing whitespace in all lines.

⬆ back to top

Naming

• (link) Use PascalCase for type and protocol names, and lowerCamelCase for everything else.

  protocol SpaceThing {
      // ...
  }
  
  class SpaceFleet: SpaceThing {
  
    enum Formation {
        // ...
    }
  
    class Spaceship {
        // ...
    }
  
    var ships: [Spaceship] = []
    static let worldName: String = "Earth"
  
    func addShip(_ ship: Spaceship) {
        // ...
    }
  }
  
  let myFleet = SpaceFleet()

• (link) Name booleans like isSpaceship, hasSpacesuit, etc. This makes it clear that they are booleans and not other types.

• (link) Acronyms in names (e.g. URL) should be all-caps except when it’s the start of a name that would otherwise be lowerCamelCase, in which case it should be uniformly lower-cased.

  // WRONG
  class UrlValidator {
  
      func isValidUrl(_ URL: URL) -> Bool {
          // ...
      }
  
      func isProfileUrl(_ URL: URL, for userId: String) -> Bool {
          // ...
      }
  }
  
  let URLValidator = UrlValidator()
  let isProfile = URLValidator.isProfileUrl(URLToTest, userId: IDOfUser)
  
  // RIGHT
  class URLValidator {
  
      func isValidURL(_ url: URL) -> Bool {
          // ...
      }
  
      func isProfileURL(_ url: URL, for userID: String) -> Bool {
          // ...
      }
  }
  
  let urlValidator = URLValidator()
  let isProfile = urlValidator.isProfileURL(urlToTest, userID: idOfUser)

• (link) Names should be written with their most general part first and their most specific part last. The meaning of "most general" depends on context, but should roughly mean "that which most helps you narrow down your search for the item you're looking for." Most importantly, be consistent with how you order the parts of your name.

  // WRONG
  let rightTitleMargin: CGFloat
  let leftTitleMargin: CGFloat
  let bodyRightMargin: CGFloat
  let bodyLeftMargin: CGFloat
  
  // RIGHT
  let titleMarginRight: CGFloat
  let titleMarginLeft: CGFloat
  let bodyMarginRight: CGFloat
  let bodyMarginLeft: CGFloat

• (link) Include a hint about type in a name if it would otherwise be ambiguous.

  // WRONG
  let title: String
  let cancel: UIButton
  
  // RIGHT
  let titleText: String
  let cancelButton: UIButton

• (link) Avoid Objective-C-style acronym prefixes. This is no longer needed to avoid naming conflicts in Swift.

  // WRONG
  class AIRAccount {
      // ...
  }
  
  // RIGHT
  class Account {
      // ...
  }

• (link) Avoid *Controller in names of classes that aren't view controllers.

  Why?

  Controller is an overloaded suffix that doesn't provide information about the responsibilities of the class.

⬆ back to top

Style

• (link) Don't include types where they can be easily inferred.

  // WRONG
  let host: Host = Host()
  
  // RIGHT
  let host = Host()

  enum Direction {
    case left
    case right
  }
  
  func someDirection() -> Direction {
    // WRONG
    return Direction.left
  
    // RIGHT
    return .left
  }

• (link) Don't use self unless it's necessary for disambiguation or required by the language.

  final class Listing {
  
      init(capacity: Int, allowsPets: Bool) {
          // WRONG
          self.capacity = capacity
          self.isFamilyFriendly = !allowsPets // `self.` not required here
  
          // RIGHT
          self.capacity = capacity
          isFamilyFriendly = !allowsPets
      }
  
      private let isFamilyFriendly: Bool
      private var capacity: Int
  
      private func increaseCapacity(by amount: Int) {
          // WRONG
          self.capacity += amount
  
          // RIGHT
          capacity += amount
  
          // WRONG
          self.save()
  
          // RIGHT
          save()
       }
  }

• (link) Bind to self when upgrading from a weak reference.

  //WRONG
  class MyClass {
  
      func request(completion: () -> Void) {
          API.request() { [weak self] response in
              guard let strongSelf = self else { return }
              // Do work
              completion()
          }
      }
  }
  
  // RIGHT
  class MyClass {
  
      func request(completion: () -> Void) {
          API.request() { [weak self] response in
              guard let self = self else { return }
              // Do work
              completion()
          }
      }
  }

• (link) Not add a trailing comma on the last element of a multi-line array.

  // WRONG
  let rowContent = [
      listingUrgencyDatesRowContent(),
      listingUrgencyBookedRowContent(),
      listingUrgencyBookedShortRowContent(),
  ]
  
  // RIGHT
  let rowContent = [
      listingUrgencyDatesRowContent(),
      listingUrgencyBookedRowContent(),
      listingUrgencyBookedShortRowContent()
  ]

• (link) Name members of tuples for extra clarity. Rule of thumb: if you've got more than 3 fields, you should probably be using a struct.

  // WRONG
  func whatever() -> (Int, Int) {
      return (4, 4)
  }
  let thing = whatever()
  print(thing.0)
  
  // RIGHT
  func whatever() -> (x: Int, y: Int) {
      return (x: 4, y: 4)
  }
  
  // THIS IS ALSO OKAY
  func whatever2() -> (x: Int, y: Int) {
      let x = 4
      let y = 4
      return (x, y)
  }
  
  let coord = whatever()
  coord.x
  coord.y

• (link) Place the colon immediately after an identifier, followed by a space.

  // WRONG
  var something : Double = 0
  
  // RIGHT
  var something: Double = 0

  // WRONG
  class MyClass : SuperClass {
      // ...
  }
  
  // RIGHT
  class MyClass: SuperClass {
      // ...
  }

  // WRONG
  var dict = [KeyType:ValueType]()
  var dict = [KeyType : ValueType]()
  
  // RIGHT
  var dict = [KeyType: ValueType]()

• (link) Place a space on either side of a return arrow for readability.

  // WRONG
  func doSomething()->String {
      // ...
  }
  
  // RIGHT
  func doSomething() -> String {
      // ...
  }

  // WRONG
  func doSomething(completion: ()->Void) {
      // ...
  }
  
  // RIGHT
  func doSomething(completion: () -> Void) {
      // ...
  }

• (link) Omit unnecessary parentheses.

  // WRONG
  if (userCount > 0) { ... }
  switch (someValue) { ... }
  let evens = userCounts.filter { (number) in number.isMultiple(of: 2) }
  let squares = userCounts.map() { $0 * $0 }
  
  // RIGHT
  if userCount > 0 { ... }
  switch someValue { ... }
  let evens = userCounts.filter { number in number.isMultiple(of: 2) }
  let squares = userCounts.map { $0 * $0 }

• (link) Omit enum associated values from case statements when all arguments are unlabeled.

  // WRONG
  if case .done(_) = result { ... }
  
  switch animal {
  case .dog(_, _, _):
      ...
  }
  
  // RIGHT
  if case .done = result { ... }
  
  switch animal {
  case .dog:
      ...
  }

• (link) When destructuring an enum case or a tuple, place the let keyword inline, adjacent to each individual property assignment.

  // WRONG
  switch result {
  case let .success(value):
      // ...
  case let .error(errorCode, errorReason):
      // ...
  }
  
  // WRONG
  guard let case .success(value) else {
      return
  }
  
  // RIGHT
  switch result {
  case .success(let value):
      // ...
  case .error(let errorCode, let errorReason):
      // ...
  }
  
  // RIGHT
  guard case .success(let value) else {
      return
  }

  Why?

  1. Consistency: We should prefer to either always inline the let keyworkd or never inline the let keyword. In Airbnb's Swift codebase, we observed that inline let is used far more often in practice (especially when destructuring enum cases with a single associated value).

  2. Clarity: Inlining the let keyword makes it more clear which identifiers are part of the conditional check and which identifiers are binding new variables, since the let keyword is always adjacent to the variable identifier.

  // `let` is adjacent to the variable identifier, so it is immediately obvious
  // at a glance that these identifiers represent new variable bindings
  case .enumCaseWithSingleAssociatedValue(let string):
  case .enumCaseWithMultipleAssociatedValues(let string, let int):
  
  // The `let` keyword is quite far from the variable identifiers,
  // so its less obvious that they represent new variable bindings
  case let .enumCaseWithSingleAssociatedValue(string):
  case let .enumCaseWithMultipleAssociatedValues(string, int):

• (link) Place function/type attributes on the line above the declaration.

  // WRONG
  @objc class Spaceship {
  
    @discardableResult func fly() -> Bool {
    }
  }
  
  // RIGHT
  
  @objc
  class Spaceship {
  
    @discardableResult
    func fly() -> Bool {
    }
  }

• (link) Multi-line arrays should have each bracket on a separate line. Put the opening and closing brackets on separate lines from any of the elements of the array.

  // WRONG
  let rowContent = [listingUrgencyDatesRowContent(),
                    listingUrgencyBookedRowContent(),
                    listingUrgencyBookedShortRowContent()]
  
  // RIGHT
  let rowContent = [
      listingUrgencyDatesRowContent(),
      listingUrgencyBookedRowContent(),
      listingUrgencyBookedShortRowContent()
  ]

• (link) Long typealiases of protocol compositions should wrap before the = and before each individual &.

  // WRONG (too long)
  public typealias Dependencies = UniverseBuilderProviding & LawsOfPhysicsProviding & UniverseSimulatorServiceProviding & PlanetBuilderProviding & CivilizationServiceProviding
  
  // WRONG (naive wrapping)
  public typealias Dependencies = UniverseBuilderProviding & LawsOfPhysicsProviding & UniverseSimulatorServiceProviding &
    PlanetBuilderProviding & CivilizationServiceProviding
  
  // WRONG (unbalanced)
  public typealias Dependencies = UniverseBuilderProviding
      & LawsOfPhysicsProviding
      & UniverseSimulatorServiceProviding
      & PlanetBuilderProviding
      & CivilizationServiceProviding
  
  // RIGHT
  public typealias Dependencies
      = UniverseBuilderProviding
      & LawsOfPhysicsProviding
      & UniverseSimulatorServiceProviding
      & PlanetBuilderProviding
      & CivilizationServiceProviding

• (link) Multi-line conditional statements should break after the first condition. Prefer using local constants or other mitigation techniques to avoid multi-line predicates where possible.

  // WRONG
  guard let earth = universe.find(
      .planet,
      named: "Earth"),
        earth.isHabitable // Strange indentation with previous line
  else { … }
  
  // RIGHT
  let earth = universe.find(
      .planet,
      named: "Earth")
  
  guard let earth = earth,
      earth.isHabitable
  else { … }
  
  // RIGHT
  if let galaxy = galaxy {
    …
  }
  
  // RIGHT
  guard let galaxy = galaxy else {
    …
  }

• (link) Indent the body and closing triple-quote of multiline string literals, unless the string literal begins on its own line in which case the string literal contents and closing triple-quote should have the same indentation as the opening triple-quote.

  // WRONG
  var spaceQuote = """
  “Space,” it says, “is big. Really big. You just won’t believe how vastly, hugely, mindbogglingly big it is.
  I mean, you may think it’s a long way down the road to the chemist’s, but that’s just peanuts to space.”
  """
  
  // RIGHT
  var spaceQuote = """
      “Space,” it says, “is big. Really big. You just won’t believe how vastly, hugely, mindbogglingly big it is.
      I mean, you may think it’s a long way down the road to the chemist’s, but that’s just peanuts to space.”
      """
  
  // WRONG
  var universeQuote: String {
      """
        In the beginning the Universe was created.
        This has made a lot of people very angry and been widely regarded as a bad move.
        """
  }
  
  // RIGHT
  var universeQuote: String {
      """
      In the beginning the Universe was created.
      This has made a lot of people very angry and been widely regarded as a bad move.
      """
  }

• (link) Use constructors instead of Make() functions for NSRange and others.

  // WRONG
  let range = NSMakeRange(10, 5)
  
  // RIGHT
  let range = NSRange(location: 10, length: 5)

• (link) For standard library types with a canonical shorthand form (Optional, Array, Dictionary), prefer using the shorthand form over the full generic form.

  // WRONG
  let optional: Optional<String> = nil
  let array: Array<String> = []
  let dictionary: Dictionary<String, Any> = [:]
  
  // RIGHT
  let optional: String? = nil
  let array: [String] = []
  let dictionary: [String: Any] = [:]

• (link) Omit explicit .init when not reqired.

  // WRONG
  let universe = Universe.init()
  
  // RIGHT
  let universe = Universe()

• (link) The opening brace following a single-line expression should be on the same line as the rest of the statement.

  // WRONG
  if !planet.isHabitable
  {
      planet.terraform()
  }
  
  class Planet
  {
      func terraform()
      {
          generateAtmosphere()
          generateOceans()
      }
  }
  
  // RIGHT
  if !planet.isHabitable {
      planet.terraform()
  }
  
  class Planet {
      func terraform() {
          generateAtmosphere()
          generateOceans()
      }
  }

• (link) The opening brace following a multi-line expression should wrap to a new line.

  // WRONG
  if let star = planet.nearestStar(),
     planet.isInHabitableZone(of: star) {
      planet.terraform()
  }
  
  class Planet {
      func terraform(
          atmosphereOptions: AtmosphereOptions = .default,
          oceanOptions: OceanOptions = .default) {
          generateAtmosphere(atmosphereOptions)
          generateOceans(oceanOptions)
      }
  }
  
  // RIGHT
  if let star = planet.nearestStar(),
     planet.isInHabitableZone(of: star)
  {
     planet.terraform()
  }
  
  class Planet {
    func terraform(
        atmosphereOptions: AtmosphereOptions = .default,
        oceanOptions: OceanOptions = .default) 
    {
        generateAtmosphere(atmosphereOptions)
        generateOceans(oceanOptions)
    }
  }

• (link) Braces should be surrounded by a single whitespace character (either a space, or a newline) on each side.

  // WRONG
  struct Planet{
      …
  }
  
  // WRONG
  if condition{
      …
  }else{
      …
  }
  
  // RIGHT
  struct Planet {
      …
  }
  
  // RIGHT
  if condition {
      …
  } else {
      …
  }

Functions

• (link) Omit Void return types from function definitions.

  // WRONG
  func doSomething() -> Void {
      ...
  }
  
  // RIGHT
  func doSomething() {
      ...
  }

• (link) Separate long function declarations with line breaks before each argument label and before the return signature. Put the open curly brace on the next line so the first executable line doesn't look like it's another parameter.

  class Universe {
  
    // WRONG
    func generateStars(at location: Point, count: Int, color: StarColor, withAverageDistance averageDistance: Float) -> String {
        // This is too long and will probably auto-wrap in a weird way
    }
  
    // WRONG
    func generateStars(at location: Point,
                       count: Int,
                       color: StarColor,
                       withAverageDistance averageDistance: Float) -> String
    {
        // Xcode indents all the arguments
    }
  
    // WRONG
    func generateStars(
        at location: Point,
        count: Int,
        color: StarColor,
        withAverageDistance averageDistance: Float) -> String {
        populateUniverse() // this line blends in with the argument list
    }
  
    // WRONG
    func generateStars(
        at location: Point,
        count: Int,
        color: StarColor,
        withAverageDistance averageDistance: Float) throws
        -> String {
        populateUniverse() // this line blends in with the argument list
    }
  
    // RIGHT
    func generateStars(
        at location: Point,
        count: Int,
        color: StarColor,
        withAverageDistance averageDistance: Float)
        -> String
    {
        populateUniverse()
    }
  
    // RIGHT
    func generateStars(
        at location: Point,
        count: Int,
        color: StarColor,
        withAverageDistance averageDistance: Float)
        throws -> String
    {
        populateUniverse()
    }
  }

• (link) Long function invocations should also break on each argument. Put the closing parenthesis on the last line of the invocation.

  // WRONG
  universe.generateStars(at: location, count: 5, color: starColor, withAverageDistance: 4)
  
  // WRONG
  universe.generateStars(at: location,
                         count: 5,
                         color: starColor,
                         withAverageDistance: 4)
  
  // WRONG
  universe.generateStars(
      at: location,
      count: 5,
      color: starColor,
      withAverageDistance: 4
  )
  
  // WRONG
  universe.generate(5,
      .stars,
      at: location)
  
  // RIGHT
  universe.generateStars(
      at: location,
      count: 5,
      color: starColor,
      withAverageDistance: 4)
  
  // RIGHT
  universe.generate(
      5,
      .stars,
      at: location)

• (link) Name unused function parameters as underscores (_).

  Why?

  Naming unused function parameters as underscores makes it more clear when the parameter is unused within the function body. This can make it easier to catch subtle logical errors, and can highlight opportunities to simplify method signatures.

  // WRONG
  
  // In this method, the `newContext` parameter is unused.
  // This is actually a logical error, and is easy to miss, but compiles without warning.
  func withContext(_ newContext: Context) {
    var updatedValue = self
    updatedValue.context = context
    return updatedValue  
  }
  
  // In this method, the `color` parameter is unused.
  // Is this a logical error (e.g. should it be passed through to the `universe.generateStars` method call),
  // or is this an unused argument that should be removed from the method signature?
  func generateUniverseWithStars(
    at location: Point,
    count: Int,
    color: StarColor,
    withAverageDistance averageDistance: Float)
  {
    let universe = generateUniverse()
    universe.generateStars(
      at: location,
      count: count,
      withAverageDistance: averageDistance)
  }

  // RIGHT
  
  // Automatically reformatting the unused parameter to be an underscore
  // makes it more clear that the parameter is unused, which makes it
  // easier to spot the logical error.
  func withContext(_: Context) {
    var updatedValue = self
    updatedValue.context = context
    return updatedValue  
  }
  
  // The underscore makes it more clear that the `color` parameter is unused.
  // This method argument can either be removed if truly unnecessary,
  // or passed through to `universe.generateStars` to correct the logical error.
  func generateUniverseWithStars(
    at location: Point,
    count: Int,
    color _: StarColor,
    withAverageDistance averageDistance: Float)
  {
    let universe = generateUniverse()
    universe.generateStars(
      at: location,
      count: count,
      withAverageDistance: averageDistance)
  }

Closures

• (link) Favor Void return types over () in closure declarations. If you must specify a Void return type in a function declaration, use Void rather than () to improve readability.

  // WRONG
  func method(completion: () -> ()) {
    ...
  }
  
  // RIGHT
  func method(completion: () -> Void) {
    ...
  }

• (link) Name unused closure parameters as underscores (_).

  Why?

  Naming unused closure parameters as underscores reduces the cognitive overhead required to read closures by making it obvious which parameters are used and which are unused.

  // WRONG
  someAsyncThing() { argument1, argument2, argument3 in
    print(argument3)
  }
  
  // RIGHT
  someAsyncThing() { _, _, argument3 in
    print(argument3)
  }

• (link) Closures should have a single space or newline inside each brace. Trailing closures should additionally have a single space or newline outside each brace.

  // WRONG
  let evenSquares = numbers.filter{$0.isMultiple(of: 2)}.map{  $0 * $0  }
  
  // RIGHT
  let evenSquares = numbers.filter { $0.isMultiple(of: 2) }.map { $0 * $0 }
  
  // WRONG
  let evenSquares = numbers.filter( { $0.isMultiple(of: 2) } ).map( { $0 * $0 } )
  
  // RIGHT
  let evenSquares = numbers.filter({ $0.isMultiple(of: 2) }).map({ $0 * $0 })
  
  // WRONG
  let evenSquares = numbers
    .filter{ 
      $0.isMultiple(of: 2) 
    }
    .map{ 
      $0 * $0 
    }
  
  // RIGHT
  let evenSquares = numbers
    .filter {
      $0.isMultiple(of: 2) 
    }
    .map {
      $0 * $0 
    }

• (link) Omit Void return types from closure expressions.

  // WRONG
  someAsyncThing() { argument -> Void in
    ...
  }
  
  // RIGHT
  someAsyncThing() { argument in
    ...
  }

Operators

• (link) Infix operators should have a single space on either side. Prefer parenthesis to visually group statements with many operators rather than varying widths of whitespace. This rule does not apply to range operators (e.g. 1...3) and postfix or prefix operators (e.g. guest? or -1).

  // WRONG
  let capacity = 1+2
  let capacity = currentCapacity   ?? 0
  let mask = (UIAccessibilityTraitButton|UIAccessibilityTraitSelected)
  let capacity=newCapacity
  let latitude = region.center.latitude - region.span.latitudeDelta/2.0
  
  // RIGHT
  let capacity = 1 + 2
  let capacity = currentCapacity ?? 0
  let mask = (UIAccessibilityTraitButton | UIAccessibilityTraitSelected)
  let capacity = newCapacity
  let latitude = region.center.latitude - (region.span.latitudeDelta / 2.0)

• (link) Long ternary operator expressions should wrap before the ? and before the :, putting each conditional branch on a separate line.

  // WRONG (too long)
  let destinationPlanet = solarSystem.hasPlanetsInHabitableZone ? solarSystem.planetsInHabitableZone.first : solarSystem.uninhabitablePlanets.first
  
  // WRONG (naive wrapping)
  let destinationPlanet = solarSystem.hasPlanetsInHabitableZone ? solarSystem.planetsInHabitableZone.first :
    solarSystem.uninhabitablePlanets.first
  
  // WRONG (unbalanced operators)
  let destinationPlanet = solarSystem.hasPlanetsInHabitableZone ?
    solarSystem.planetsInHabitableZone.first :
    solarSystem.uninhabitablePlanets.first
  
  // RIGHT
  let destinationPlanet = solarSystem.hasPlanetsInHabitableZone
    ? solarSystem.planetsInHabitableZone.first
    : solarSystem.uninhabitablePlanets.first

⬆ back to top

Patterns

• (link) Prefer initializing properties at init time whenever possible, rather than using implicitly unwrapped optionals. A notable exception is UIViewController's view property.

  // WRONG
  class MyClass {
  
    init() {
      super.init()
      someValue = 5
    }
  
    var someValue: Int!
  }
  
  // RIGHT
  class MyClass {
  
    init() {
      someValue = 0
      super.init()
    }
  
    var someValue: Int
  }

• (link) Avoid performing any meaningful or time-intensive work in init(). Avoid doing things like opening database connections, making network requests, reading large amounts of data from disk, etc. Create something like a start() method if these things need to be done before an object is ready for use.

• (link) Extract complex property observers into methods. This reduces nestedness, separates side-effects from property declarations, and makes the usage of implicitly-passed parameters like oldValue explicit.

  // WRONG
  class TextField {
    var text: String? {
      didSet {
        guard oldValue != text else {
          return
        }
  
        // Do a bunch of text-related side-effects.
      }
    }
  }
  
  // RIGHT
  class TextField {
    var text: String? {
      didSet { textDidUpdate(from: oldValue) }
    }
  
    private func textDidUpdate(from oldValue: String?) {
      guard oldValue != text else {
        return
      }
  
      // Do a bunch of text-related side-effects.
    }
  }

• (link) Extract complex callback blocks into methods. This limits the complexity introduced by weak-self in blocks and reduces nestedness. If you need to reference self in the method call, make use of guard to unwrap self for the duration of the callback.

  //WRONG
  class MyClass {
  
    func request(completion: () -> Void) {
      API.request() { [weak self] response in
        if let self = self {
          // Processing and side effects
        }
        completion()
      }
    }
  }
  
  // RIGHT
  class MyClass {
  
    func request(completion: () -> Void) {
      API.request() { [weak self] response in
        guard let self = self else { return }
        self.doSomething(with: self.property, response: response)
        completion()
      }
    }
  
    func doSomething(with nonOptionalParameter: SomeClass, response: SomeResponseClass) {
      // Processing and side effects
    }
  }

• (link) Prefer using guard at the beginning of a scope.

  Why?

  It's easier to reason about a block of code when all guard statements are grouped together at the top rather than intermixed with business logic.

• (link) Access control should be at the strictest level possible. Prefer public to open and private to fileprivate unless you need that behavior.

  // WRONG
  public struct Spaceship {
    // WRONG: `engine` is used in `extension Spaceship` below,
    // but extensions in the same file can access `private` members.
    fileprivate let engine: AntimatterEngine
  
    // WRONG: `hull` is not used by any other type, so `fileprivate` is unnecessary. 
    fileprivate let hull: Hull
  
    // RIGHT: `navigation` is used in `extension Pilot` below,
    // so `fileprivate` is necessary here.
    fileprivate let navigation: SpecialRelativityNavigationService
  }
  
  extension Spaceship {
    public func blastOff() {
      engine.start()
    }
  }
  
  extension Pilot {
    public func chartCourse() {
      spaceship.navigation.course = .andromedaGalaxy
      spaceship.blastOff()
    }
  }

  // RIGHT
  public struct Spaceship {
    fileprivate let navigation: SpecialRelativityNavigationService
    private let engine: AntimatterEngine
    private let hull: Hull
  }
  
  extension Spaceship {
    public func blastOff() {
      engine.start()
    }
  }
  
  extension Pilot {
    public func chartCourse() {
      spaceship.navigation.course = .andromedaGalaxy
      spaceship.blastOff()
    }
  }

• (link) Avoid global functions whenever possible. Prefer methods within type definitions.

  // WRONG
  func age(of person, bornAt timeInterval) -> Int {
    // ...
  }
  
  func jump(person: Person) {
    // ...
  }
  
  // RIGHT
  class Person {
    var bornAt: TimeInterval
  
    var age: Int {
      // ...
    }
  
    func jump() {
      // ...
    }
  }

• (link) Use caseless enums for organizing public or internal constants and functions into namespaces.

  • Avoid creating non-namespaced global constants and functions.
  • Feel free to nest namespaces where it adds clarity.
  • private globals are permitted, since they are scoped to a single file and do not pollute the global namespace. Consider placing private globals in an enum namespace to match the guidelines for other declaration types.

  Why?

  Caseless enums work well as namespaces because they cannot be instantiated, which matches their intent.

  enum Environment {
  
    enum Earth {
      static let gravity = 9.8
    }
  
    enum Moon {
      static let gravity = 1.6
    }
  }

• (link) Use Swift's automatic enum values unless they map to an external source. Add a comment explaining why explicit values are defined.

  Why?

  To minimize user error, improve readability, and write code faster, rely on Swift's automatic enum values. If the value maps to an external source (e.g. it's coming from a network request) or is persisted across binaries, however, define the values explicity, and document what these values are mapping to.

  This ensures that if someone adds a new value in the middle, they won't accidentally break things.

  // WRONG
  enum ErrorType: String {
    case error = "error"
    case warning = "warning"
  }
  
  enum UserType: String {
    case owner
    case manager
    case member
  }
  
  enum Planet: Int {
    case mercury = 0
    case venus = 1
    case earth = 2
    case mars = 3
    case jupiter = 4
    case saturn = 5
    case uranus = 6
    case neptune = 7
  }
  
  enum ErrorCode: Int {
    case notEnoughMemory
    case invalidResource
    case timeOut
  }
  
  // RIGHT
  enum ErrorType: String {
    case error
    case warning
  }
  
  /// These are written to a logging service. Explicit values ensure they're consistent across binaries.
  // swiftformat:disable redundantRawValues
  enum UserType: String {
    case owner = "owner"
    case manager = "manager"
    case member = "member"
  }
  // swiftformat:enable redundantRawValues
  
  enum Planet: Int {
    case mercury
    case venus
    case earth
    case mars
    case jupiter
    case saturn
    case uranus
    case neptune
  }
  
  /// These values come from the server, so we set them here explicitly to match those values.
  enum ErrorCode: Int {
    case notEnoughMemory = 0
    case invalidResource = 1
    case timeOut = 2
  }

• (link) Use optionals only when they have semantic meaning.

• (link) Prefer immutable values whenever possible. Use map and compactMap instead of appending to a new collection. Use filter instead of removing elements from a mutable collection.

  Why?

  Mutable variables increase complexity, so try to keep them in as narrow a scope as possible.

  // WRONG
  var results = [SomeType]()
  for element in input {
    let result = transform(element)
    results.append(result)
  }
  
  // RIGHT
  let results = input.map { transform($0) }

  // WRONG
  var results = [SomeType]()
  for element in input {
    if let result = transformThatReturnsAnOptional(element) {
      results.append(result)
    }
  }
  
  // RIGHT
  let results = input.compactMap { transformThatReturnsAnOptional($0) }

• (link) Prefer immutable or computed static properties over mutable ones whenever possible. Use stored static let properties or computed static var properties over stored static vars properties whenever possible, as stored static var properties are global mutable state.

  Why?

  Global mutable state increases complexity and makes it harder to reason about the behavior of applications. It should be avoided when possible.

  // WRONG
  enum Fonts {
    static var title = UIFont(…)
  }
  
  // RIGHT
  enum Fonts {
    static let title = UIFont(…)
  }

  // WRONG
  struct FeatureState {
    var count: Int
  
    static var initial = FeatureState(count: 0)
  }
  
  // RIGHT
  struct FeatureState {
    var count: Int
  
    static var initial: FeatureState {
      // Vend static properties that are cheap to compute
      FeatureState(count: 0)
    }
  }

• (link) Handle an unexpected but recoverable condition with an assert method combined with the appropriate logging in production. If the unexpected condition is not recoverable, prefer a precondition method or fatalError(). This strikes a balance between crashing and providing insight into unexpected conditions in the wild. Only prefer fatalError over a precondition method when the failure message is dynamic, since a precondition method won't report the message in the crash report.

  func didSubmitText(_ text: String) {
    // It's unclear how this was called with an empty string; our custom text field shouldn't allow this.
    // This assert is useful for debugging but it's OK if we simply ignore this scenario in production.
    guard !text.isEmpty else {
      assertionFailure("Unexpected empty string")
      return
    }
    // ...
  }
  
  func transformedItem(atIndex index: Int, from items: [Item]) -> Item {
    precondition(index >= 0 && index < items.count)
    // It's impossible to continue executing if the precondition has failed.
    // ...
  }
  
  func makeImage(name: String) -> UIImage {
    guard let image = UIImage(named: name, in: nil, compatibleWith: nil) else {
      fatalError("Image named \(name) couldn't be loaded.")
      // We want the error message so we know the name of the missing image.
    }
    return image
  }

• (link) Default type methods to static.

  Why?

  If a method needs to be overridden, the author should opt into that functionality by using the class keyword instead.

  // WRONG
  class Fruit {
    class func eatFruits(_ fruits: [Fruit]) { ... }
  }
  
  // RIGHT
  class Fruit {
    static func eatFruits(_ fruits: [Fruit]) { ... }
  }

• (link) Default classes to final.

  Why?

  If a class needs to be overridden, the author should opt into that functionality by omitting the final keyword.

  // WRONG
  class SettingsRepository {
    // ...
  }
  
  // RIGHT
  final class SettingsRepository {
    // ...
  }

• (link) Check for nil rather than using optional binding if you don't need to use the value.

  Why?

  Checking for nil makes it immediately clear what the intent of the statement is. Optional binding is less explicit.

  var thing: Thing?
  
  // WRONG
  if let _ = thing {
    doThing()
  }
  
  // RIGHT
  if thing != nil {
    doThing()
  }

• (link) Omit the return keyword when not required by the language.

  // WRONG
  ["1", "2", "3"].compactMap { return Int($0) }
  
  var size: CGSize {
    return CGSize(
      width: 100.0,
      height: 100.0)
  }
  
  func makeInfoAlert(message: String) -> UIAlertController {
    return UIAlertController(
      title: "ℹ️ Info",
      message: message,
      preferredStyle: .alert)
  }
  
  // RIGHT
  ["1", "2", "3"].compactMap { Int($0) }
  
  var size: CGSize {
    CGSize(
      width: 100.0,
      height: 100.0)
  }
  
  func makeInfoAlert(message: String) -> UIAlertController {
    UIAlertController(
      title: "ℹ️ Info",
      message: message,
      preferredStyle: .alert)
  }

• (link) Use AnyObject instead of class in protocol definitions.

  Why?

  SE-0156, which introduced support for using the AnyObject keyword as a protocol constraint, recommends preferring AnyObject over class:

  This proposal merges the concepts of class and AnyObject, which now have the same meaning: they represent an existential for classes. To get rid of the duplication, we suggest only keeping AnyObject around. To reduce source-breakage to a minimum, class could be redefined as typealias class = AnyObject and give a deprecation warning on class for the first version of Swift this proposal is implemented in. Later, class could be removed in a subsequent version of Swift.

  // WRONG
  protocol Foo: class {}
  
  // RIGHT
  protocol Foo: AnyObject {}

• (link) Avoid single-expression closures that are always called immediately. Instead, prefer inlining the expression.

  // WRONG
  lazy var universe: Universe = { 
    Universe() 
  }()
  
  lazy var stars = {
    universe.generateStars(
      at: location,
      count: 5,
      color: starColor,
      withAverageDistance: 4)
  }()
  
  // RIGHT
  lazy var universe = Universe() 
  
  lazy var stars = universe.generateStars(
    at: location,
    count: 5,
    color: starColor,
    withAverageDistance: 4)

• (link) Omit the get clause from a computed property declaration that doesn't also have a set, willSet, or didSet clause.

  // WRONG
  var universe: Universe {
    get {
      Universe()
    }
  }
  
  // RIGHT
  var universe: Universe {
    Universe()
  }
  
  // RIGHT
  var universe: Universe {
    get { multiverseService.current }
    set { multiverseService.current = newValue }
  }

⬆ back to top

File Organization

• (link) Alphabetize and deduplicate module imports within a file. Place all imports at the top of the file below the header comments. Do not add additional line breaks between import statements. Add a single empty line before the first import and after the last import.

  Why?

  • A standard organization method helps engineers more quickly determine which modules a file depends on.
  • Duplicated import statements have no effect and should be removed for clarity.

  // WRONG
  
  //  Copyright © 2018 Airbnb. All rights reserved.
  //
  import DLSPrimitives
  import Constellation
  import Constellation
  import Epoxy
  
  import Foundation
  
  //RIGHT
  
  //  Copyright © 2018 Airbnb. All rights reserved.
  //
  
  import Constellation
  import DLSPrimitives
  import Epoxy
  import Foundation

  Exception: @testable import should be grouped after the regular import and separated by an empty line.

  // WRONG
  
  //  Copyright © 2018 Airbnb. All rights reserved.
  //
  
  import DLSPrimitives
  @testable import Epoxy
  import Foundation
  import Nimble
  import Quick
  
  //RIGHT
  
  //  Copyright © 2018 Airbnb. All rights reserved.
  //
  
  import DLSPrimitives
  import Foundation
  import Nimble
  import Quick
  
  @testable import Epoxy

• (link) Limit consecutive whitespace to one blank line or space (excluding indentation). Favor the following formatting guidelines over whitespace of varying heights or widths.

  // WRONG
  struct Planet {
  
    let mass:          Double
    let hasAtmosphere: Bool
  
  
    func distance(to: Planet) { }
  
  }
  
  // RIGHT
  struct Planet {
  
    let mass: Double
    let hasAtmosphere: Bool
  
    func distance(to: Planet) { }
  
  }

• (link) Files should end in a newline.

• (link) Declarations that include scopes spanning multiple lines should be separated from adjacent declarations in the same scope by a newline. Insert a single blank line between multi-line scoped declarations (e.g. types, extensions, functions, computed properties, etc.) and other declarations at the same indentation level.

  Why?

  Dividing scoped declarations from other declarations at the same scope visually separates them, making adjacent declarations easier to differentiate from the scoped declaration.

  // WRONG
  struct SolarSystem {
    var numberOfPlanets: Int {
      …
    }
    func distance(to: SolarSystem) -> AstronomicalUnit {
      …
    }
  }
  struct Galaxy {
    func distance(to: Galaxy) -> AstronomicalUnit {
      …
    }
    func contains(_ solarSystem: SolarSystem) -> Bool {
      …
    }
  }
  
  // RIGHT
  struct SolarSystem {
    var numberOfPlanets: Int {
      …
    }
  
    func distance(to: SolarSystem) -> AstronomicalUnit {
      …
    }
  }
  
  struct Galaxy {
    func distance(to: Galaxy) -> AstronomicalUnit {
      …
    }
  
    func contains(_ solarSystem: SolarSystem) -> Bool {
      …
    }
  }

• (link) Use // MARK: to separate the contents of type definitions and extensions into the sections listed below, in order. All type definitions and extensions should be divided up in this consistent way, allowing a reader of your code to easily jump to what they are interested in.

  • // MARK: Lifecycle for init and deinit methods.
  • // MARK: Open for open properties and methods.
  • // MARK: Public for public properties and methods.
  • // MARK: Internal for internal properties and methods.
  • // MARK: Fileprivate for fileprivate properties and methods.
  • // MARK: Private for private properties and methods.
  • If the type in question is an enum, its cases should go above the first // MARK:.
  • Do not subdivide each of these sections into subsections, as it makes the method dropdown more cluttered and therefore less useful. Instead, group methods by functionality and use smart naming to make clear which methods are related. If there are enough methods that sub-sections seem necessary, consider refactoring your code into multiple types.
  • If all of the type or extension's definitions belong to the same category (e.g. the type or extension only consists of internal properties), it is OK to omit the // MARK:s.
  • If the type in question is a simple value type (e.g. fewer than 20 lines), it is OK to omit the // MARK:s, as it would hurt legibility.

• (link) Within each top-level section, place content in the following order. This allows a new reader of your code to more easily find what they are looking for.

  • Nested types and typealiases
  • Static properties
  • Class properties
  • Instance properties
  • Static methods
  • Class methods
  • Instance methods

• (link) Add empty lines between property declarations of different kinds. (e.g. between static properties and instance properties.)

  // WRONG
  static let gravityEarth: CGFloat = 9.8
  static let gravityMoon: CGFloat = 1.6
  var gravity: CGFloat
  
  // RIGHT
  static let gravityEarth: CGFloat = 9.8
  static let gravityMoon: CGFloat = 1.6
  
  var gravity: CGFloat

• (link) Computed properties and properties with property observers should appear at the end of the set of declarations of the same kind. (e.g. instance properties.)

  // WRONG
  var atmosphere: Atmosphere {
    didSet {
      print("oh my god, the atmosphere changed")
    }
  }
  var gravity: CGFloat
  
  // RIGHT
  var gravity: CGFloat
  var atmosphere: Atmosphere {
    didSet {
      print("oh my god, the atmosphere changed")
    }
  }

⬆ back to top

Objective-C Interoperability

• (link) Prefer pure Swift classes over subclasses of NSObject. If your code needs to be used by some Objective-C code, wrap it to expose the desired functionality. Use @objc on individual methods and variables as necessary rather than exposing all API on a class to Objective-C via @objcMembers.

  class PriceBreakdownViewController {
  
    private let acceptButton = UIButton()
  
    private func setUpAcceptButton() {
      acceptButton.addTarget(
        self,
        action: #selector(didTapAcceptButton),
        forControlEvents: .touchUpInside)
    }
  
    @objc
    private func didTapAcceptButton() {
      // ...
    }
  }

⬆ back to top

Contributors

• View Contributors

⬆ back to top

Amendments

We encourage you to fork this guide and change the rules to fit your team’s style guide. Below, you may list some amendments to the style guide. This allows you to periodically update your style guide without having to deal with merge conflicts.

⬆ back to top