{"id":13465251,"url":"https://github.com/airbnb/swift","last_synced_at":"2025-05-13T22:04:27.141Z","repository":{"id":37561539,"uuid":"63729462","full_name":"airbnb/swift","owner":"airbnb","description":"Airbnb's Swift Style Guide","archived":false,"fork":false,"pushed_at":"2025-05-09T16:00:02.000Z","size":613,"stargazers_count":2577,"open_issues_count":1,"forks_count":338,"subscribers_count":50,"default_branch":"master","last_synced_at":"2025-05-09T17:21:55.867Z","etag":null,"topics":["ios","naming-conventions","style-guide","styleguide","swift","swiftformat","swiftlint"],"latest_commit_sha":null,"homepage":"","language":"Markdown","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/airbnb.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE.md","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2016-07-19T21:33:28.000Z","updated_at":"2025-05-09T16:00:06.000Z","dependencies_parsed_at":"2023-12-15T15:30:59.184Z","dependency_job_id":"22d5d942-36bf-4236-a420-4b698d2ba56b","html_url":"https://github.com/airbnb/swift","commit_stats":{"total_commits":434,"total_committers":45,"mean_commits":9.644444444444444,"dds":0.7580645161290323,"last_synced_commit":"8b2776fe3decb6fd801a0e10924eec990e9b4b57"},"previous_names":[],"tags_count":9,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/airbnb%2Fswift","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/airbnb%2Fswift/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/airbnb%2Fswift/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/airbnb%2Fswift/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/airbnb","download_url":"https://codeload.github.com/airbnb/swift/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254036814,"owners_count":22003653,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ios","naming-conventions","style-guide","styleguide","swift","swiftformat","swiftlint"],"created_at":"2024-07-31T15:00:24.846Z","updated_at":"2025-05-13T22:04:27.130Z","avatar_url":"https://github.com/airbnb.png","language":"Markdown","funding_links":[],"categories":["Guides","Markdown","Style Guides [🔝](#readme)","Guides and Learning","Swift"],"sub_categories":["Style Guides","Ruby on Rails"],"readme":"# Airbnb Swift Style Guide\n\n[![](https://img.shields.io/endpoint?url=https%3A%2F%2Fswiftpackageindex.com%2Fapi%2Fpackages%2Fairbnb%2Fswift%2Fbadge%3Ftype%3Dswift-versions)](https://swiftpackageindex.com/airbnb/swift)\n\n## Goals\n\nFollowing this style guide should:\n\n* Make it easier to read and begin understanding unfamiliar code.\n* Make code easier to maintain.\n* Reduce simple programmer errors.\n* Reduce cognitive load while coding.\n* Keep discussions on diffs focused on the code's logic rather than its style.\n\nNote 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.\n\n## Guiding Tenets\n\n* This guide is in addition to the official [Swift API Design Guidelines](https://swift.org/documentation/api-design-guidelines/). These rules should not contradict that document.\n* These rules should not fight Xcode's \u003ckbd\u003e^\u003c/kbd\u003e + \u003ckbd\u003eI\u003c/kbd\u003e indentation behavior.\n* We strive to make every rule lintable:\n  * If a rule changes the format of the code, it needs to be able to be reformatted automatically (either using [SwiftFormat](https://github.com/nicklockwood/SwiftFormat) or [SwiftLint](https://github.com/realm/SwiftLint) autocorrect).\n  * For rules that don't directly change the format of the code, we should have a lint rule that throws a warning.\n  * Exceptions to these rules should be rare and heavily justified.\n\n## Swift Package Manager command plugin\n\nThis repo includes a Swift Package Manager command plugin that you can use to automatically reformat or lint your package according to the style guide. To use this command plugin with your package, all you need to do is add this repo as a dependency:\n\n```swift\ndependencies: [\n  .package(url: \"https://github.com/airbnb/swift\", from: \"1.0.0\"),\n]\n```\n\nand then run the `format` command plugin in your package directory:\n\n```shell\n$ swift package format\n```\n\n\u003cdetails\u003e\n\u003csummary\u003eUsage guide\u003c/summary\u003e\n\n```shell\n# Supported in Xcode 14+. Prompts for permission to write to the package directory.\n$ swift package format\n\n# When using the Xcode 13 toolchain, or a noninteractive shell, you must use:\n$ swift package --allow-writing-to-package-directory format\n\n# To just lint without reformatting, you can use `--lint`:\n$ swift package format --lint\n\n# By default the command plugin runs on the entire package directory.\n# You can exclude directories using `exclude`:\n$ swift package format --exclude Tests\n\n# Alternatively you can explicitly list the set of paths and/or SPM targets:\n$ swift package format --paths Sources Tests Package.swift\n$ swift package format --targets AirbnbSwiftFormatTool\n\n# The plugin infers your package's minimum Swift version from the `swift-tools-version`\n# in your `Package.swift`, but you can provide a custom value with `--swift-version`:\n$ swift package format --swift-version 5.3\n```\n\nThe package plugin returns a non-zero exit code if there is a lint failure that requires attention.\n - In `--lint` mode, any lint failure from any tool will result in a non-zero exit code.\n - In standard autocorrect mode without `--lint`, only failures from SwiftLint lint-only rules will result in a non-zero exit code.\n\n\u003c/details\u003e\n\n## Table of Contents\n\n1. [Xcode Formatting](#xcode-formatting)\n1. [Naming](#naming)\n1. [Style](#style)\n    1. [Functions](#functions)\n    1. [Closures](#closures)\n    1. [Operators](#operators)\n1. [Patterns](#patterns)\n1. [File Organization](#file-organization)\n1. [Objective-C Interoperability](#objective-c-interoperability)\n1. [Contributors](#contributors)\n1. [Amendments](#amendments)\n\n## Xcode Formatting\n\n_You can enable the following settings in Xcode by running [this script](resources/xcode_settings.bash), e.g. as part of a \"Run Script\" build phase._\n\n* \u003ca id='column-width'\u003e\u003c/a\u003e(\u003ca href='#column-width'\u003elink\u003c/a\u003e) **Each line should have a maximum column width of 100 characters.** [![SwiftFormat: wrap](https://img.shields.io/badge/SwiftFormat-wrap-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#wrap)\n\n  \u003cdetails\u003e\n\n  #### Why?\n  Due to larger screen sizes, we have opted to choose a page guide greater than 80.\n\n  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.\n\n  \u003c/details\u003e\n\n* \u003ca id='spaces-over-tabs'\u003e\u003c/a\u003e(\u003ca href='#spaces-over-tabs'\u003elink\u003c/a\u003e) **Use 2 spaces to indent lines.** [![SwiftFormat: indent](https://img.shields.io/badge/SwiftFormat-indent-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#indent)\n\n* \u003ca id='trailing-whitespace'\u003e\u003c/a\u003e(\u003ca href='#trailing-whitespace'\u003elink\u003c/a\u003e) **Trim trailing whitespace in all lines.** [![SwiftFormat: trailingSpace](https://img.shields.io/badge/SwiftFormat-trailingSpace-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#trailingSpace)\n\n**[⬆ back to top](#table-of-contents)**\n\n## Naming\n\n* \u003ca id='use-camel-case'\u003e\u003c/a\u003e(\u003ca href='#use-camel-case'\u003elink\u003c/a\u003e) **Use PascalCase for type and protocol names, and lowerCamelCase for everything else.**\n\n  \u003cdetails\u003e\n\n  ```swift\n  protocol SpaceThing {\n    // ...\n  }\n\n  class SpaceFleet: SpaceThing {\n\n    enum Formation {\n      // ...\n    }\n\n    class Spaceship {\n      // ...\n    }\n\n    var ships: [Spaceship] = []\n    static let worldName: String = \"Earth\"\n\n    func addShip(_ ship: Spaceship) {\n      // ...\n    }\n  }\n\n  let myFleet = SpaceFleet()\n  ```\n\n  \u003c/details\u003e\n\n  _Exception: You may prefix a private property with an underscore if it is backing an identically-named property or method with a higher access level._\n\n  \u003cdetails\u003e\n\n  #### Why?\n  There are specific scenarios where a backing property or method that is prefixed with an underscore could be easier to read than using a more descriptive name.\n\n  - Type erasure\n\n  ```swift\n  public final class AnyRequester\u003cModelType\u003e: Requester {\n\n    public init\u003cT: Requester\u003e(_ requester: T) where T.ModelType == ModelType {\n      _executeRequest = requester.executeRequest\n    }\n\n    @discardableResult\n    public func executeRequest(\n      _ request: URLRequest,\n      onSuccess: @escaping (ModelType, Bool) -\u003e Void,\n      onFailure: @escaping (Error) -\u003e Void)\n      -\u003e URLSessionCancellable\n    {\n      return _executeRequest(request, onSuccess, onFailure)\n    }\n\n    private let _executeRequest: (\n      URLRequest,\n      @escaping (ModelType, Bool) -\u003e Void,\n      @escaping (Error) -\u003e Void)\n      -\u003e URLSessionCancellable\n  }\n  ```\n\n  - Backing a less specific type with a more specific type\n\n  ```swift\n  final class ExperiencesViewController: UIViewController {\n    // We can't name this view since UIViewController has a view: UIView property.\n    private lazy var _view = CustomView()\n\n    loadView() {\n      self.view = _view\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='bool-names'\u003e\u003c/a\u003e(\u003ca href='#bool-names'\u003elink\u003c/a\u003e) **Name booleans like `isSpaceship`, `hasSpacesuit`, etc.** This makes it clear that they are booleans and not other types.\n\n* \u003ca id='capitalize-acronyms'\u003e\u003c/a\u003e(\u003ca href='#capitalize-acronyms'\u003elink\u003c/a\u003e) **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.**\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  class UrlValidator {\n\n    func isValidUrl(_ URL: URL) -\u003e Bool {\n      // ...\n    }\n\n    func isProfileUrl(_ URL: URL, for userId: String) -\u003e Bool {\n      // ...\n    }\n  }\n\n  let URLValidator = UrlValidator()\n  let isProfile = URLValidator.isProfileUrl(URLToTest, userId: IDOfUser)\n\n  // RIGHT\n  class URLValidator {\n\n    func isValidURL(_ url: URL) -\u003e Bool {\n      // ...\n    }\n\n    func isProfileURL(_ url: URL, for userID: String) -\u003e Bool {\n      // ...\n    }\n  }\n\n  let urlValidator = URLValidator()\n  let isProfile = urlValidator.isProfileURL(urlToTest, userID: idOfUser)\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='general-part-first'\u003e\u003c/a\u003e(\u003ca href='#general-part-first'\u003elink\u003c/a\u003e) **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.\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  let rightTitleMargin: CGFloat\n  let leftTitleMargin: CGFloat\n  let bodyRightMargin: CGFloat\n  let bodyLeftMargin: CGFloat\n\n  // RIGHT\n  let titleMarginRight: CGFloat\n  let titleMarginLeft: CGFloat\n  let bodyMarginRight: CGFloat\n  let bodyMarginLeft: CGFloat\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='hint-at-types'\u003e\u003c/a\u003e(\u003ca href='#hint-at-types'\u003elink\u003c/a\u003e) **Include a hint about type in a name if it would otherwise be ambiguous.**\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  let title: String\n  let cancel: UIButton\n\n  // RIGHT\n  let titleText: String\n  let cancelButton: UIButton\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='past-tense-events'\u003e\u003c/a\u003e(\u003ca href='#past-tense-events'\u003elink\u003c/a\u003e) **Event-handling functions should be named like past-tense sentences.** The subject can be omitted if it's not needed for clarity.\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  class ExperiencesViewController {\n\n    private func handleBookButtonTap() {\n      // ...\n    }\n\n    private func modelChanged() {\n      // ...\n    }\n  }\n\n  // RIGHT\n  class ExperiencesViewController {\n\n    private func didTapBookButton() {\n      // ...\n    }\n\n    private func modelDidChange() {\n      // ...\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='avoid-class-prefixes'\u003e\u003c/a\u003e(\u003ca href='#avoid-class-prefixes'\u003elink\u003c/a\u003e) **Avoid Objective-C-style acronym prefixes.** This is no longer needed to avoid naming conflicts in Swift.\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  class AIRAccount {\n    // ...\n  }\n\n  // RIGHT\n  class Account {\n    // ...\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='avoid-controller-suffix'\u003e\u003c/a\u003e(\u003ca href='#avoid-controller-suffix'\u003elink\u003c/a\u003e) **Avoid `*Controller` in names of classes that aren't view controllers.**\n  \u003cdetails\u003e\n\n  #### Why?\n  Controller is an overloaded suffix that doesn't provide information about the responsibilities of the class.\n\n  \u003c/details\u003e\n\n**[⬆ back to top](#table-of-contents)**\n\n## Style\n\n* \u003ca id='use-implicit-types'\u003e\u003c/a\u003e(\u003ca href='#use-implicit-types'\u003elink\u003c/a\u003e) **Don't include types where they can be easily inferred.** [![SwiftFormat: redundantType](https://img.shields.io/badge/SwiftFormat-redundantType-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#redundantType)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  let sun: Star = Star(mass: 1.989e30)\n  let earth: Planet = Planet.earth\n\n  // RIGHT\n  let sun = Star(mass: 1.989e30)\n  let earth = Planet.earth\n\n  // NOT RECOMMENDED. However, since the linter doesn't have full type information, this is not enforced automatically.\n  let moon: Moon = earth.moon // returns `Moon`\n\n  // RIGHT\n  let moon = earth.moon\n  let moon: PlanetaryBody? = earth.moon\n\n  // WRONG: Most literals provide a default type that can be inferred.\n  let enableGravity: Bool = true\n  let numberOfPlanets: Int = 8\n  let sunMass: Double = 1.989e30\n\n  // RIGHT\n  let enableGravity = true\n  let numberOfPlanets = 8\n  let sunMass = 1.989e30\n  \n  // WRONG: Types can be inferred from if/switch expressions as well if each branch has the same explicit type.\n  let smallestPlanet: Planet =\n    if treatPlutoAsPlanet {\n      Planet.pluto\n    } else {\n      Planet.mercury\n    }\n\n  // RIGHT\n  let smallestPlanet =\n    if treatPlutoAsPlanet {\n      Planet.pluto\n    } else {\n      Planet.mercury\n    }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='infer-property-types'\u003e\u003c/a\u003e(\u003ca href='#infer-property-types'\u003elink\u003c/a\u003e) **Prefer letting the type of a variable or property be inferred from the right-hand-side value rather than writing the type explicitly on the left-hand side.** [![SwiftFormat: propertyTypes](https://img.shields.io/badge/SwiftFormat-propertyTypes-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#propertyTypes)\n\n  \u003cdetails\u003e\n\n  Prefer using inferred types when the right-hand-side value is a static member with a leading dot (e.g. an `init`, a `static` property / function, or an enum case). This applies to both local variables and property declarations:\n\n  ```swift\n  // WRONG\n  struct SolarSystemBuilder {\n    let sun: Star = .init(mass: 1.989e30)\n    let earth: Planet = .earth\n\n    func setUp() {\n      let galaxy: Galaxy = .andromeda\n      let system: SolarSystem = .init(sun, earth)\n      galaxy.add(system)\n    }\n  }\n  \n  // RIGHT\n  struct SolarSystemBuilder {\n    let sun = Star(mass: 1.989e30)\n    let earth = Planet.earth\n\n    func setUp() {\n      let galaxy = Galaxy.andromeda\n      let system = SolarSystem(sun, earth)\n      galaxy.add(system)\n    }\n  }\n  ```\n\n  Explicit types are still permitted in other cases:\n\n  ```swift\n  // RIGHT: There is no right-hand-side value, so an explicit type is required.\n  let sun: Star\n\n  // RIGHT: The right-hand-side is not a static member of the left-hand type.\n  let moon: PlantaryBody = earth.moon\n  let sunMass: Float = 1.989e30\n  let planets: [Planet] = []\n  let venusMoon: Moon? = nil\n  ```\n\n  There are some rare cases where the inferred type syntax has a different meaning than the explicit type syntax. In these cases, the explicit type syntax is still permitted:\n\n  ```swift\n  extension String {\n    static let earth = \"Earth\"\n  }\n\n  // WRONG: fails with \"error: type 'String?' has no member 'earth'\"\n  let planetName = String?.earth\n\n  // RIGHT\n  let planetName: String? = .earth\n  ```\n\n  ```swift\n  struct SaturnOutline: ShapeStyle { ... }\n\n  extension ShapeStyle where Self == SaturnOutline {\n    static var saturnOutline: SaturnOutline { \n      SaturnOutline() \n    }\n  }\n\n  // WRONG: fails with \"error: static member 'saturnOutline' cannot be used on protocol metatype '(any ShapeStyle).Type'\"\n  let myShape2 = (any ShapeStyle).myShape\n\n  // RIGHT: If the property's type is an existential / protocol type, moving the type\n  // to the right-hand side will result in invalid code if the value is defined in an\n  // extension like `extension ShapeStyle where Self == SaturnOutline`.\n  // SwiftFormat autocorrect detects this case by checking for the existential `any` keyword.\n  let myShape1: any ShapeStyle = .saturnOutline\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='omit-self'\u003e\u003c/a\u003e(\u003ca href='#omit-self'\u003elink\u003c/a\u003e) **Don't use `self` unless it's necessary for disambiguation or required by the language.** [![SwiftFormat: redundantSelf](https://img.shields.io/badge/SwiftFormat-redundantSelf-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#redundantSelf)\n\n  \u003cdetails\u003e\n\n  ```swift\n  final class Listing {\n\n    init(capacity: Int, allowsPets: Bool) {\n      // WRONG\n      self.capacity = capacity\n      self.isFamilyFriendly = !allowsPets // `self.` not required here\n\n      // RIGHT\n      self.capacity = capacity\n      isFamilyFriendly = !allowsPets\n    }\n\n    private let isFamilyFriendly: Bool\n    private var capacity: Int\n\n    private func increaseCapacity(by amount: Int) {\n      // WRONG\n      self.capacity += amount\n\n      // RIGHT\n      capacity += amount\n\n      // WRONG\n      self.save()\n\n      // RIGHT\n      save()\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='upgrade-self'\u003e\u003c/a\u003e(\u003ca href='#upgrade-self'\u003elink\u003c/a\u003e) **Bind to `self` when upgrading from a weak reference.** [![SwiftFormat: strongifiedSelf](https://img.shields.io/badge/SwiftFormat-strongifiedSelf-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#strongifiedSelf)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  class MyClass {\n\n    func request(completion: () -\u003e Void) {\n      API.request() { [weak self] response in\n        guard let strongSelf = self else { return }\n        // Do work\n        completion()\n      }\n    }\n  }\n\n  // RIGHT\n  class MyClass {\n\n    func request(completion: () -\u003e Void) {\n      API.request() { [weak self] response in\n        guard let self else { return }\n        // Do work\n        completion()\n      }\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='trailing-comma-array'\u003e\u003c/a\u003e(\u003ca href='#trailing-comma-array'\u003elink\u003c/a\u003e) **Add a trailing comma on the last element of a multi-line array.** [![SwiftFormat: trailingCommas](https://img.shields.io/badge/SwiftFormat-trailingCommas-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#trailingCommas)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  let rowContent = [\n    listingUrgencyDatesRowContent(),\n    listingUrgencyBookedRowContent(),\n    listingUrgencyBookedShortRowContent()\n  ]\n\n  // RIGHT\n  let rowContent = [\n    listingUrgencyDatesRowContent(),\n    listingUrgencyBookedRowContent(),\n    listingUrgencyBookedShortRowContent(),\n  ]\n  ```\n\n* \u003ca id='no-space-inside-collection-brackets'\u003e\u003c/a\u003e(\u003ca href='#no-space-inside-brackets'\u003elink\u003c/a\u003e) **There should be no spaces inside the brackets of collection literals.** [![SwiftFormat: spaceInsideBrackets](https://img.shields.io/badge/SwiftFormat-spaceInsideBrackets-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#spaceInsideBrackets)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  let innerPlanets = [ mercury, venus, earth, mars ]\n  let largestObjects = [ .star: sun, .planet: jupiter  ]\n\n  // RIGHT\n  let innerPlanets = [mercury, venus, earth, mars]\n  let largestObjects = [.star: sun, .planet: jupiter]\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='name-tuple-elements'\u003e\u003c/a\u003e(\u003ca href='#name-tuple-elements'\u003elink\u003c/a\u003e) **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.\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  func whatever() -\u003e (Int, Int) {\n    return (4, 4)\n  }\n  let thing = whatever()\n  print(thing.0)\n\n  // RIGHT\n  func whatever() -\u003e (x: Int, y: Int) {\n    return (x: 4, y: 4)\n  }\n\n  // THIS IS ALSO OKAY\n  func whatever2() -\u003e (x: Int, y: Int) {\n    let x = 4\n    let y = 4\n    return (x, y)\n  }\n\n  let coord = whatever()\n  coord.x\n  coord.y\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='colon-spacing'\u003e\u003c/a\u003e(\u003ca href='#colon-spacing'\u003elink\u003c/a\u003e) **Colons should always be followed by a space, but not preceded by a space**. [![SwiftFormat: spaceAroundOperators](https://img.shields.io/badge/SwiftFormat-spaceAroundOperators-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#spacearoundoperators)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  let planet:CelestialObject = sun.planets[0]\n  let planet : CelestialObject = sun.planets[0]\n\n  // RIGHT\n  let planet: CelestialObject = sun.planets[0]\n  ```\n\n  ```swift\n  // WRONG\n  class Planet : CelestialObject {\n    // ...\n  }\n\n  // RIGHT\n  class Planet: CelestialObject {\n    // ...\n  }\n  ```\n\n  ```swift\n  // WRONG\n  let moons: [Planet : Moon] = [\n    mercury : [], \n    venus : [], \n    earth : [theMoon], \n    mars : [phobos,deimos],\n  ]\n\n  // RIGHT\n  let moons: [Planet: Moon] = [\n    mercury: [], \n    venus: [], \n    earth: [theMoon], \n    mars: [phobos,deimos],\n  ]\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='return-arrow-spacing'\u003e\u003c/a\u003e(\u003ca href='#return-arrow-spacing'\u003elink\u003c/a\u003e) **Place a space on either side of a return arrow for readability.** [![SwiftFormat: spaceAroundOperators](https://img.shields.io/badge/SwiftFormat-spaceAroundOperators-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#spacearoundoperators)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  func doSomething()-\u003eString {\n    // ...\n  }\n\n  // RIGHT\n  func doSomething() -\u003e String {\n    // ...\n  }\n  ```\n\n  ```swift\n  // WRONG\n  func doSomething(completion: ()-\u003eVoid) {\n    // ...\n  }\n\n  // RIGHT\n  func doSomething(completion: () -\u003e Void) {\n    // ...\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='unnecessary-parens'\u003e\u003c/a\u003e(\u003ca href='#unnecessary-parens'\u003elink\u003c/a\u003e) **Omit unnecessary parentheses.** [![SwiftFormat: redundantParens](https://img.shields.io/badge/SwiftFormat-redundantParens-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#redundantParens)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  if (userCount \u003e 0) { ... }\n  switch (someValue) { ... }\n  let evens = userCounts.filter { (number) in number.isMultiple(of: 2) }\n  let squares = userCounts.map() { $0 * $0 }\n\n  // RIGHT\n  if userCount \u003e 0 { ... }\n  switch someValue { ... }\n  let evens = userCounts.filter { number in number.isMultiple(of: 2) }\n  let squares = userCounts.map { $0 * $0 }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='unnecessary-enum-arguments'\u003e\u003c/a\u003e (\u003ca href='#unnecessary-enum-arguments'\u003elink\u003c/a\u003e) **Omit enum associated values from case statements when all arguments are unlabeled.** [![SwiftFormat: redundantPattern](https://img.shields.io/badge/SwiftFormat-redundantPattern-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#redundantPattern)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  if case .done(_) = result { ... }\n\n  switch animal {\n  case .dog(_, _, _):\n    ...\n  }\n\n  // RIGHT\n  if case .done = result { ... }\n\n  switch animal {\n  case .dog:\n    ...\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='inline-let-when-destructuring'\u003e\u003c/a\u003e (\u003ca href='#inline-let-when-destructuring'\u003elink\u003c/a\u003e) **When destructuring an enum case or a tuple, place the `let` keyword inline, adjacent to each individual property assignment.** [![SwiftFormat: hoistPatternLet](https://img.shields.io/badge/SwiftFormat-hoistPatternLet-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#hoistPatternLet)\n\n  \u003cdetails\u003e\n\n    ```swift\n    // WRONG\n    switch result {\n    case let .success(value):\n      // ...\n    case let .error(errorCode, errorReason):\n      // ...\n    }\n\n    // WRONG\n    guard let case .success(value) else {\n      return\n    }\n\n    // RIGHT\n    switch result {\n    case .success(let value):\n      // ...\n    case .error(let errorCode, let errorReason):\n      // ...\n    }\n\n    // RIGHT\n    guard case .success(let value) else {\n      return\n    }\n    ```\n\n    #### Why?\n\n    1. **Consistency**: We should prefer to either _always_ inline the `let` keyword or _never_ inline the `let` keyword. In Airbnb's Swift codebase, we [observed](https://github.com/airbnb/swift/pull/126#discussion_r631979244) that inline `let` is used far more often in practice (especially when destructuring enum cases with a single associated value).\n\n    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.\n\n    ```swift\n    // `let` is adjacent to the variable identifier, so it is immediately obvious\n    // at a glance that these identifiers represent new variable bindings\n    case .enumCaseWithSingleAssociatedValue(let string):\n    case .enumCaseWithMultipleAssociatedValues(let string, let int):\n\n    // The `let` keyword is quite far from the variable identifiers,\n    // so it is less obvious that they represent new variable bindings\n    case let .enumCaseWithSingleAssociatedValue(string):\n    case let .enumCaseWithMultipleAssociatedValues(string, int):\n\n    ```\n\n  \u003c/details\u003e\n\n* \u003ca id='attributes-on-prev-line'\u003e\u003c/a\u003e(\u003ca href='#attributes-on-prev-line'\u003elink\u003c/a\u003e) **Place attributes for functions, types, and computed properties on the line above the declaration**. [![SwiftFormat: wrapAttributes](https://img.shields.io/badge/SwiftFormat-wrapAttributes-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#wrapAttributes)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  @objc class Spaceship {\n\n    @ViewBuilder var controlPanel: some View {\n      // ...\n    }\n\n    @discardableResult func fly() -\u003e Bool {\n      // ...\n    }\n\n  }\n\n  // RIGHT\n  @objc\n  class Spaceship {\n\n    @ViewBuilder\n    var controlPanel: some View {\n      // ...\n    }\n\n    @discardableResult\n    func fly() -\u003e Bool {\n      // ...\n    }\n\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='simple-stored-property-attributes-on-same-line'\u003e\u003c/a\u003e(\u003ca href='#simple-stored-property-attributes-on-same-line'\u003elink\u003c/a\u003e) **Place simple attributes for stored properties on the same line as the rest of the declaration**. Complex attributes with named arguments, or more than one unnamed argument, should be placed on the previous line. [![SwiftFormat: wrapAttributes](https://img.shields.io/badge/SwiftFormat-wrapAttributes-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#wrapAttributes)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG. These simple property wrappers should be written on the same line as the declaration. \n  struct SpaceshipDashboardView {\n\n    @State\n    private var warpDriveEnabled: Bool\n\n    @ObservedObject\n    private var lifeSupportService: LifeSupportService\n\n    @Environment(\\.controlPanelStyle) \n    private var controlPanelStyle\n\n  }\n\n  // RIGHT\n  struct SpaceshipDashboardView {\n\n    @State private var warpDriveEnabled: Bool\n\n    @ObservedObject private var lifeSupportService: LifeSupportService\n\n    @Environment(\\.controlPanelStyle) private var controlPanelStyle\n\n  }\n  ```\n\n  ```swift\n  // WRONG. These complex attached macros should be written on the previous line.\n  struct SolarSystemView {\n\n    @Query(sort: \\.distance) var allPlanets: [Planet]\n\n    @Query(sort: \\.age, order: .reverse) var moonsByAge: [Moon]\n\n  }\n\n  // RIGHT\n  struct SolarSystemView {\n\n    @Query(sort: \\.distance)\n    var allPlanets: [Planet]\n\n    @Query(sort: \\.age, order: .reverse)\n    var oldestMoons: [Moon]\n\n  }\n  ```\n\n  ```swift\n  // WRONG. These long, complex attributes should be written on the previous line.\n  struct RocketFactory {\n\n    @available(*, unavailable, message: \"No longer in production\") var saturn5Builder: Saturn5Builder\n\n    @available(*, deprecated, message: \"To be retired by 2030\") var atlas5Builder: Atlas5Builder\n\n    @available(*, iOS 18.0, tvOS 18.0, macOS 15.0, watchOS 11.0) var newGlennBuilder: NewGlennBuilder\n\n  }\n\n  // RIGHT\n  struct RocketFactory {\n\n    @available(*, unavailable, message: \"No longer in production\")\n    var saturn5Builder: Saturn5Builder\n\n    @available(*, deprecated, message: \"To be retired by 2030\")\n    var atlas5Builder: Atlas5Builder\n    \n    @available(*, iOS 18.0, tvOS 18.0, macOS 15.0, watchOS 11.0)\n    var newGlennBuilder: NewGlennBuilder\n\n  }\n  ```\n  \n  #### Why?\n  \n  Unlike other types of declarations, which have braces and span multiple lines, stored property declarations are often only a single line of code. Stored properties are often written sequentially without any blank lines between them. This makes the code compact without hurting readability, and allows for related properties to be grouped together in blocks:\n  \n  ```swift\n  struct SpaceshipDashboardView {\n    @State private var warpDriveEnabled: Bool\n    @State private var lifeSupportEnabled: Bool\n    @State private var artificialGravityEnabled: Bool\n    @State private var tractorBeamEnabled: Bool\n    \n    @Environment(\\.controlPanelStyle) private var controlPanelStyle\n    @Environment(\\.toggleButtonStyle) private var toggleButtonStyle\n  }\n  ```\n  \n  If stored property attributes were written on the previous line (like other types of attributes), then the properties start to visually bleed together unless you add blank lines between them:\n  \n  ```swift\n  struct SpaceshipDashboardView {\n    @State\n    private var warpDriveEnabled: Bool\n    @State\n    private var lifeSupportEnabled: Bool\n    @State\n    private var artificialGravityEnabled: Bool\n    @State\n    private var tractorBeamEnabled: Bool\n    \n    @Environment(\\.controlPanelStyle)\n    private var controlPanelStyle\n    @Environment(\\.toggleButtonStyle)\n    private var toggleButtonStyle\n  }\n  ```\n  \n  If you add blank lines, the list of properties becomes much longer and you lose the ability to group related properties together:  \n  \n  ```swift\n  struct SpaceshipDashboardView {\n    @State\n    private var warpDriveEnabled: Bool\n    \n    @State\n    private var lifeSupportEnabled: Bool\n    \n    @State\n    private var artificialGravityEnabled: Bool\n    \n    @State\n    private var tractorBeamEnabled: Bool\n    \n    @Environment(\\.controlPanelStyle)\n    private var controlPanelStyle\n    \n    @Environment(\\.toggleButtonStyle)\n    private var toggleButtonStyle\n  }\n  ```\n  \n  This doesn't apply to complex attributes with named arguments, or multiple unnamed arguments. These arguments are visually complex and typically encode a lot of information, so feel cramped and difficult to read when written on a single line:\n\n  ```swift\n  // Despite being less than 100 characters long, these lines are very complex and feel unnecessarily long: \n  @available(*, unavailable, message: \"No longer in production\") var saturn5Builder: Saturn5Builder\n  @available(*, deprecated, message: \"To be retired by 2030\") var atlas5Builder: Atlas5Builder\n  @available(*, iOS 18.0, tvOS 18.0, macOS 15.0, watchOS 11.0) var newGlennBuilder: NewGlennBuilder\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='multi-line-array'\u003e\u003c/a\u003e(\u003ca href='#multi-line-array'\u003elink\u003c/a\u003e) **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. Also add a trailing comma on the last element. [![SwiftFormat: wrapArguments](https://img.shields.io/badge/SwiftFormat-wrapArguments-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#wrapArguments)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  let rowContent = [listingUrgencyDatesRowContent(),\n                    listingUrgencyBookedRowContent(),\n                    listingUrgencyBookedShortRowContent()]\n\n  // WRONG\n  let rowContent = [\n    listingUrgencyDatesRowContent(),\n    listingUrgencyBookedRowContent(),\n    listingUrgencyBookedShortRowContent()\n  ]\n\n  // RIGHT\n  let rowContent = [\n    listingUrgencyDatesRowContent(),\n    listingUrgencyBookedRowContent(),\n    listingUrgencyBookedShortRowContent(),\n  ]\n  ```\n\n* \u003ca id='long-typealias'\u003e\u003c/a\u003e(\u003ca href='#long-typealias'\u003elink\u003c/a\u003e) [Long](https://github.com/airbnb/swift#column-width) type aliases of protocol compositions should wrap before the `=` and before each individual `\u0026`. [![SwiftFormat: wrapArguments](https://img.shields.io/badge/SwiftFormat-wrapArguments-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#wrapArguments)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG (too long)\n  public typealias Dependencies = CivilizationServiceProviding \u0026 LawsOfPhysicsProviding \u0026 PlanetBuilderProviding \u0026 UniverseBuilderProviding \u0026 UniverseSimulatorServiceProviding\n\n  // WRONG (naive wrapping)\n  public typealias Dependencies = CivilizationServiceProviding \u0026 LawsOfPhysicsProviding \u0026 PlanetBuilderProviding \u0026\n    UniverseBuilderProviding \u0026 UniverseSimulatorServiceProviding\n\n  // WRONG (unbalanced)\n  public typealias Dependencies = CivilizationServiceProviding\n    \u0026 LawsOfPhysicsProviding\n    \u0026 PlanetBuilderProviding\n    \u0026 UniverseBuilderProviding\n    \u0026 UniverseSimulatorServiceProviding\n\n  // RIGHT\n  public typealias Dependencies\n    = CivilizationServiceProviding\n    \u0026 LawsOfPhysicsProviding\n    \u0026 PlanetBuilderProviding\n    \u0026 UniverseBuilderProviding\n    \u0026 UniverseSimulatorServiceProviding\n  ```\n\n* \u003ca id='sort-typealiases'\u003e\u003c/a\u003e(\u003ca href='#sort-typealiases'\u003elink\u003c/a\u003e) **Sort protocol composition type aliases alphabetically.** [![SwiftFormat: sortTypealiases](https://img.shields.io/badge/SwiftFormat-sortTypealiases-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#sortTypealiases)\n\n  \u003cdetails\u003e\n\n  #### Why?\n\n  Protocol composition type aliases are an unordered list with no natural ordering. Sorting alphabetically keeps these lists more organized, which is especially valuable for long protocol compositions.\n\n  ```swift\n  // WRONG (not sorted)\n  public typealias Dependencies\n    = UniverseBuilderProviding\n    \u0026 LawsOfPhysicsProviding\n    \u0026 UniverseSimulatorServiceProviding\n    \u0026 PlanetBuilderProviding\n    \u0026 CivilizationServiceProviding\n\n  // RIGHT\n  public typealias Dependencies\n    = CivilizationServiceProviding\n    \u0026 LawsOfPhysicsProviding\n    \u0026 PlanetBuilderProviding\n    \u0026 UniverseBuilderProviding\n    \u0026 UniverseSimulatorServiceProviding\n  ```\n\n* \u003ca id='prefer-if-let-shorthand'\u003e\u003c/a\u003e(\u003ca href='#prefer-if-let-shorthand'\u003elink\u003c/a\u003e) Omit the right-hand side of the expression when unwrapping an optional property to a non-optional property with the same name. [![SwiftFormat: redundantOptionalBinding](https://img.shields.io/badge/SwiftFormat-redundantOptionalBinding-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#redundantOptionalBinding)\n\n  \u003cdetails\u003e\n\n  #### Why?\n\n  Following the rationale in [SE-0345](https://github.com/apple/swift-evolution/blob/main/proposals/0345-if-let-shorthand.md), this shorthand syntax removes unnecessary boilerplate while retaining clarity.\n\n  ```swift\n  // WRONG\n  if\n    let galaxy = galaxy,\n    galaxy.name == \"Milky Way\"\n  { … }\n\n  guard\n    let galaxy = galaxy,\n    galaxy.name == \"Milky Way\"\n  else { … }\n\n  // RIGHT\n  if\n    let galaxy,\n    galaxy.name == \"Milky Way\"\n  { … }\n\n  guard\n    let galaxy,\n    galaxy.name == \"Milky Way\"\n  else { … }\n  ```\n\n* \u003ca id='else-on-same-line'\u003e\u003c/a\u003e(\u003ca href='#else-on-same-line'\u003elink\u003c/a\u003e) **Else statements should start on the same line as the previous condition's closing brace, unless the conditions are separated by a blank line or comments.** [![SwiftFormat: elseOnSameLine](https://img.shields.io/badge/SwiftFormat-elseOnSameLine-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#elseOnSameLine)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  if let galaxy {\n    …\n  }\n  else if let bigBangService {\n    …\n  }\n  else {\n    …\n  }\n\n  // RIGHT\n  if let galaxy {\n    …\n  } else if let bigBangService {\n    …\n  } else {\n    …\n  }\n\n  // RIGHT, because there are comments between the conditions\n  if let galaxy {\n    …\n  }\n  // If the galaxy hasn't been created yet, create it using the big bang service\n  else if let bigBangService {\n    …\n  }\n  // If the big bang service doesn't exist, fail gracefully\n  else {\n    …\n  }\n\n  // RIGHT, because there are blank lines between the conditions\n  if let galaxy {\n    …\n  }\n\n  else if let bigBangService {\n    // If the galaxy hasn't been created yet, create it using the big bang service\n    …\n  }\n\n  else {\n    // If the big bang service doesn't exist, fail gracefully\n    …\n  }\n  ```\n\n* \u003ca id='multi-line-conditions'\u003e\u003c/a\u003e(\u003ca href='#multi-line-conditions'\u003elink\u003c/a\u003e) **Multi-line conditional statements should break after the leading keyword.** Indent each individual statement by [2 spaces](https://github.com/airbnb/swift#spaces-over-tabs). [![SwiftFormat: wrapArguments](https://img.shields.io/badge/SwiftFormat-wrapArguments-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#wrapArguments)\n\n  \u003cdetails\u003e\n\n  #### Why?\n  Breaking after the leading keyword resets indentation to the standard [2-space grid](https://github.com/airbnb/swift#spaces-over-tabs),\n  which helps avoid fighting Xcode's \u003ckbd\u003e^\u003c/kbd\u003e + \u003ckbd\u003eI\u003c/kbd\u003e indentation behavior.\n\n  ```swift\n  // WRONG\n  if let galaxy,\n    galaxy.name == \"Milky Way\" // Indenting by two spaces fights Xcode's ^+I indentation behavior\n  { … }\n\n  // WRONG\n  guard let galaxy,\n        galaxy.name == \"Milky Way\" // Variable width indentation (6 spaces)\n  else { … }\n\n  // WRONG\n  guard let earth = universe.find(\n    .planet,\n    named: \"Earth\"),\n    earth.isHabitable // Blends in with previous condition's method arguments\n  else { … }\n\n  // RIGHT\n  if\n    let galaxy,\n    galaxy.name == \"Milky Way\"\n  { … }\n\n  // RIGHT\n  guard\n    let galaxy,\n    galaxy.name == \"Milky Way\"\n  else { … }\n\n  // RIGHT\n  guard\n    let earth = universe.find(\n      .planet,\n      named: \"Earth\"),\n    earth.isHabitable\n  else { … }\n\n  // RIGHT\n  if let galaxy {\n    …\n  }\n\n  // RIGHT\n  guard let galaxy else {\n    …\n  }\n  ```\n  \n  \u003c/details\u003e\n\n* \u003ca id='wrap-multiline-conditional-assignment'\u003e\u003c/a\u003e(\u003ca href='#wrap-multiline-conditional-assignment'\u003elink\u003c/a\u003e) **Add a line break after the assignment operator (`=`) before a multi-line `if` or `switch` expression**, and indent the following `if` / `switch` expression. If the declaration fits on a single line, a line break is not required. [![SwiftFormat: wrapMultilineConditionalAssignment](https://img.shields.io/badge/SwiftFormat-wrapMultilineConditionalAssignment-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#wrapMultilineConditionalAssignment)\n\n  \u003cdetails\u003e\n\n  #### Why?\n  \n  This makes it so that `if` and `switch` expressions always have the same \"shape\" as standard `if` and `switch` statements, where:\n  1. The `if` / `switch` keyword is always the left-most token on a dedicated line of code.\n  2. The conditional branches are always to the right of and below the `if` / `switch` keyword.\n\n  This is most consistent with how the `if` / `switch` keywords are used for control flow, and thus makes it easier to recognize that the code is using an `if` or `switch` expression at a glance. \n  \n  ```swift\n  // WRONG. Should have a line break after the first `=`. \n  let planetLocation = if let star = planet.star {\n    \"The \\(star.name) system\"\n   } else {\n    \"Rogue planet\"\n  }\n\n  // WRONG. The first `=` should be on the line of the variable being assigned.\n  let planetLocation \n    = if let star = planet.star {\n      \"The \\(star.name) system\"\n    } else {\n      \"Rogue planet\"\n    }\n\n  // WRONG. `switch` expression should be indented.\n  let planetLocation =\n  switch planet {\n  case .mercury, .venus, .earth, .mars:\n    .terrestrial\n  case .jupiter, .saturn, .uranus, .neptune:\n    .gasGiant\n  }\n    \n  // RIGHT \n  let planetLocation = \n    if let star = planet.star {\n      \"The \\(star.name) system\"\n    } else {\n      \"Rogue planet\"\n    }\n    \n  // RIGHT\n  let planetType: PlanetType =\n    switch planet {\n    case .mercury, .venus, .earth, .mars:\n      .terrestrial\n    case .jupiter, .saturn, .uranus, .neptune:\n      .gasGiant\n    }\n    \n  // ALSO RIGHT. A line break is not required because the declaration fits on a single line. \n  let moonName = if let moon = planet.moon { moon.name } else { \"none\" }\n\n  // ALSO RIGHT. A line break is permitted if it helps with readability.\n  let moonName =\n    if let moon = planet.moon { moon.name } else { \"none\" }\n  ```\n  \n  \u003c/details\u003e\n\n* \u003ca id='prefer-conditional-assignment-to-control-flow'\u003e\u003c/a\u003e(\u003ca href='#prefer-conditional-assignment-to-control-flow'\u003elink\u003c/a\u003e) **When initializing a new property with the result of a conditional statement (e.g. an `if` or `switch` statement), use a single `if`/`switch` expression where possible** rather than defining an uninitialized property and initializing it on every branch of the following conditional statement. [![SwiftFormat: conditionalAssignment](https://img.shields.io/badge/SwiftFormat-conditionalAssignment-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#conditionalAssignment)\n\n  \u003cdetails\u003e\n\n  #### Why?\n\n  There are several benefits to using an `if`/`switch` expression over simply performing assignment on each branch of the following conditional statement:\n  1. In most cases, you no longer need to explicitly write a type annotation for the variable that is being assigned to.\n  2. The compiler will diagnose more cases where using a mutable `var` is unnecessary.\n  3. The resulting syntax is visually lighter because the property name being assigned doesn't need to be written on each branch.\n\n  ```swift\n  // BEFORE\n  // 1. An explicit type annotation is required for the uninitialized property.\n  // 2. `var` is unnecessary here because `planetLocation` is never modified after being initialized, but the compiler doesn't diagnose.\n  // 3. The `planetLocation` property name is written on each branch so is redundant and visually noisy.\n  var planetLocation: String\n  if let star = planet.star {\n    planetLocation = \"The \\(star.name) system\"\n  } else {\n    planetLocation = \"Rogue planet\"\n  }\n\n  print(planetLocation)\n\n  // AFTER\n  // 1. No need to write an explicit `: String` type annotation.\n  // 2. The compiler correctly diagnoses that the `var` is unnecessary and emits a warning suggesting to use `let` instead. \n  // 3. Each conditional branch is simply the value being assigned.\n  var planetLocation =\n    if let star = planet.star {\n      \"The \\(star.name) system\"\n    } else {\n      \"Rogue planet\"\n    }\n\n  print(planetLocation)\n  ```\n\n  #### Examples\n\n  ```swift\n  // WRONG\n  let planetLocation: String\n  if let star = planet.star {\n    planetLocation = \"The \\(star.name) system\"\n  } else {\n    planetLocation = \"Rogue planet\"\n  }\n\n  let planetType: PlanetType\n  switch planet {\n  case .mercury, .venus, .earth, .mars:\n    planetType = .terrestrial\n  case .jupiter, .saturn, .uranus, .neptune:\n    planetType = .gasGiant\n  }\n\n  let canBeTerraformed: Bool \n  if \n    let star = planet.star, \n    !planet.isHabitable,\n    planet.isInHabitableZone(of: star) \n  {\n    canBeTerraformed = true\n  } else {\n    canBeTerraformed = false\n  }\n\n  // RIGHT\n  let planetLocation =\n    if let star = planet.star {\n      \"The \\(star.name) system\"\n    } else {\n      \"Rogue planet\"\n    }\n\n  let planetType: PlanetType =\n    switch planet {\n    case .mercury, .venus, .earth, .mars:\n      .terrestrial\n    case .jupiter, .saturn, .uranus, .neptune:\n      .gasGiant\n    }\n\n  let canBeTerraformed =\n    if \n      let star = planet.star, \n      !planet.isHabitable,\n      planet.isInHabitableZone(of: star) \n    {\n      true\n    } else {\n      false\n    }\n\n  // ALSO RIGHT. This example cannot be converted to an if/switch expression\n  // because one of the branches is more than just a single expression.\n  let planetLocation: String\n  if let star = planet.star {\n    planetLocation = \"The \\(star.name) system\"\n  } else {\n    let actualLocaton = galaxy.name ?? \"the universe\"\n    planetLocation = \"Rogue planet somewhere in \\(actualLocation)\"\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='blank-line-after-multiline-switch-case'\u003e\u003c/a\u003e(\u003ca href='#blank-line-after-multiline-switch-case'\u003elink\u003c/a\u003e) **Insert a blank line following a switch case with a multi-line body.** Spacing within an individual switch statement should be consistent. If any case has a multi-line body then all cases should include a trailing blank line. The last switch case doesn't need a blank line, since it is already followed by a closing brace. [![SwiftFormat: blankLineAfterSwitchCase](https://img.shields.io/badge/SwiftFormat-blankLineAfterSwitchCase-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#blankLineAfterSwitchCase) [![SwiftFormat: consistentSwitchCaseSpacing](https://img.shields.io/badge/SwiftFormat-consistentSwitchCaseSpacing-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#consistentSwitchCaseSpacing)\n\n  \u003cdetails\u003e\n\n  #### Why?\n\n  Like with [declarations in a file](#newline-between-scope-siblings), inserting a blank line between scopes makes them easier to visually differentiate.\n  \n  Complex switch statements are visually busy without blank lines between the cases, making it more difficult to read the code and harder to distinguish between individual cases at a glance. Blank lines between the individual cases make complex switch statements easier to read.\n\n  #### Examples\n\n  ```swift\n  // WRONG. These switch cases should be followed by a blank line.\n  func handle(_ action: SpaceshipAction) {\n    switch action {\n    case .engageWarpDrive:\n      navigationComputer.destination = targetedDestination\n      warpDrive.spinUp()\n      warpDrive.activate()\n    case .enableArtificialGravity:\n      artificialGravityEngine.enable(strength: .oneG)\n    case .scanPlanet(let planet):\n      scanner.target = planet\n      scanner.scanAtmosphere()\n      scanner.scanBiosphere()\n      scanner.scanForArtificialLife()\n    case .handleIncomingEnergyBlast:\n      energyShields.engage()\n    }\n  }\n\n  // WRONG. While the `.enableArtificialGravity` case isn't multi-line, the other cases are.\n  // For consistency, it should also include a trailing blank line.\n  func handle(_ action: SpaceshipAction) {\n    switch action {\n    case .engageWarpDrive:\n      navigationComputer.destination = targetedDestination\n      warpDrive.spinUp()\n      warpDrive.activate()\n\n    case .enableArtificialGravity:\n      artificialGravityEngine.enable(strength: .oneG)\n    case .scanPlanet(let planet):\n      scanner.target = planet\n      scanner.scanAtmosphere()\n      scanner.scanBiosphere()\n      scanner.scanForArtificialLife()\n      \n    case .handleIncomingEnergyBlast:\n      energyShields.engage()\n    }\n  }\n\n  // RIGHT. All of the cases have a trailing blank line.\n  func handle(_ action: SpaceshipAction) {\n    switch action {\n    case .engageWarpDrive:\n      navigationComputer.destination = targetedDestination\n      warpDrive.spinUp()\n      warpDrive.activate()\n\n    case .enableArtificialGravity:\n      artificialGravityEngine.enable(strength: .oneG)\n\n    case .scanPlanet(let planet):\n      scanner.target = planet\n      scanner.scanAtmosphere()\n      scanner.scanBiosphere()\n      scanner.scanForArtificialLife()\n      \n    case .handleIncomingEnergyBlast:\n      energyShields.engage()\n    }\n  }\n\n  // RIGHT. Since none of the cases are multi-line, blank lines are not required.\n  func handle(_ action: SpaceshipAction) {\n    switch action {\n    case .engageWarpDrive:\n      warpDrive.engage()\n    case .enableArtificialGravity:\n      artificialGravityEngine.enable(strength: .oneG)\n    case .scanPlanet(let planet):\n      scanner.scan(planet)\n    case .handleIncomingEnergyBlast:\n      energyShields.engage()\n    }\n  }\n\n  // ALSO RIGHT. Blank lines are still permitted after single-line switch cases if it helps with readability.\n  func handle(_ action: SpaceshipAction) {\n    switch action {\n    case .engageWarpDrive:\n      warpDrive.engage()\n\n    case .enableArtificialGravity:\n      artificialGravityEngine.enable(strength: .oneG)\n\n    case .scanPlanet(let planet):\n      scanner.scan(planet)\n\n    case .handleIncomingEnergyBlast:\n      energyShields.engage()\n    }\n  }\n\n  // WRONG. While it's fine to use blank lines to separate cases, spacing within a single switch statement should be consistent.\n  func handle(_ action: SpaceshipAction) {\n    switch action {\n    case .engageWarpDrive:\n      warpDrive.engage()\n    case .enableArtificialGravity:\n      artificialGravityEngine.enable(strength: .oneG)\n    case .scanPlanet(let planet):\n      scanner.scan(planet)\n\n    case .handleIncomingEnergyBlast:\n      energyShields.engage()\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='wrap-guard-else'\u003e\u003c/a\u003e(\u003ca href='#wrap-guard-else'\u003elink\u003c/a\u003e) **Add a line break before the `else` keyword in a multi-line guard statement.** For single-line guard statements, keep the `else` keyword on the same line as the `guard` keyword. The open brace should immediately follow the `else` keyword. [![SwiftFormat: elseOnSameLine](https://img.shields.io/badge/SwiftFormat-elseOnSameLine-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#elseOnSameLine)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG (else should be on its own line for multi-line guard statements)\n  guard\n    let galaxy,\n    galaxy.name == \"Milky Way\" else\n  { … }\n\n  // WRONG (else should be on the same line for single-line guard statements)\n  guard let galaxy\n  else { … }\n\n  // RIGHT\n  guard\n    let galaxy,\n    galaxy.name == \"Milky Way\"\n  else { … }\n\n  // RIGHT\n  guard let galaxy else {\n    …\n  }\n  ```\n\n* \u003ca id='indent-multiline-string-literals'\u003e\u003c/a\u003e(\u003ca href='#indent-multiline-string-literals'\u003elink\u003c/a\u003e) **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. [![SwiftFormat: indent](https://img.shields.io/badge/SwiftFormat-indent-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#indent)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  var spaceQuote = \"\"\"\n  “Space,” it says, “is big. Really big. You just won’t believe how vastly, hugely, mindbogglingly big it is.\n  I mean, you may think it’s a long way down the road to the chemist’s, but that’s just peanuts to space.”\n  \"\"\"\n\n  // RIGHT\n  var spaceQuote = \"\"\"\n    “Space,” it says, “is big. Really big. You just won’t believe how vastly, hugely, mindbogglingly big it is.\n    I mean, you may think it’s a long way down the road to the chemist’s, but that’s just peanuts to space.”\n    \"\"\"\n\n  // WRONG\n  var universeQuote: String {\n    \"\"\"\n      In the beginning the Universe was created.\n      This has made a lot of people very angry and been widely regarded as a bad move.\n      \"\"\"\n  }\n\n  // RIGHT\n  var universeQuote: String {\n    \"\"\"\n    In the beginning the Universe was created.\n    This has made a lot of people very angry and been widely regarded as a bad move.\n    \"\"\"\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='favor-constructors'\u003e\u003c/a\u003e(\u003ca href='#favor-constructors'\u003elink\u003c/a\u003e) **Use constructors instead of Make() functions for NSRange and others.** [![SwiftLint: legacy_constructor](https://img.shields.io/badge/SwiftLint-legacy__constructor-007A87.svg)](https://realm.github.io/SwiftLint/legacy_constructor)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  let range = NSMakeRange(10, 5)\n\n  // RIGHT\n  let range = NSRange(location: 10, length: 5)\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='standard-library-type-shorthand'\u003e\u003c/a\u003e(\u003ca href='#standard-library-type-sugar'\u003elink\u003c/a\u003e) **For standard library types with a canonical shorthand form (`Optional`, `Array`, `Dictionary`), prefer using the shorthand form over the full generic form.** [![SwiftFormat: typeSugar](https://img.shields.io/badge/SwiftFormat-typeSugar-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#typeSugar)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  let optional: Optional\u003cString\u003e = nil\n  let array: Array\u003cString\u003e = []\n  let dictionary: Dictionary\u003cString, Any\u003e = [:]\n\n  // RIGHT\n  let optional: String? = nil\n  let array: [String] = []\n  let dictionary: [String: Any] = [:]\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='omit-explicit-init'\u003e\u003c/a\u003e(\u003ca href='#omit-explicit-init'\u003elink\u003c/a\u003e) **Omit explicit `.init` when not required.** [![SwiftFormat: redundantInit](https://img.shields.io/badge/SwiftFormat-redundantInit-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#redundantInit)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  let universe = Universe.init()\n\n  // RIGHT\n  let universe = Universe()\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='single-line-expression-braces'\u003e\u003c/a\u003e(\u003ca href='#single-line-expression-braces'\u003elink\u003c/a\u003e) The opening brace following a single-line expression should be on the same line as the rest of the statement. [![SwiftFormat: braces](https://img.shields.io/badge/SwiftFormat-braces-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#braces)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  if !planet.isHabitable\n  {\n    planet.terraform()\n  }\n\n  class Planet\n  {\n    func terraform()\n    {\n      generateAtmosphere()\n      generateOceans()\n    }\n  }\n\n  // RIGHT\n  if !planet.isHabitable {\n    planet.terraform()\n  }\n\n  class Planet {\n    func terraform() {\n      generateAtmosphere()\n      generateOceans()\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='multi-line-expression-braces'\u003e\u003c/a\u003e(\u003ca href='#multi-line-expression-braces'\u003elink\u003c/a\u003e) The opening brace following a multi-line expression should wrap to a new line. [![SwiftFormat: wrapMultilineStatementBraces](https://img.shields.io/badge/SwiftFormat-wrapMultilineStatementBraces-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#wrapMultilineStatementBraces)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  if\n    let star = planet.nearestStar(),\n    planet.isInHabitableZone(of: star) {\n    planet.terraform()\n  }\n\n  class Planet {\n    func terraform(\n      atmosphereOptions: AtmosphereOptions = .default,\n      oceanOptions: OceanOptions = .default) {\n      generateAtmosphere(atmosphereOptions)\n      generateOceans(oceanOptions)\n    }\n  }\n\n  // RIGHT\n  if\n    let star = planet.nearestStar(),\n    planet.isInHabitableZone(of: star)\n  {\n    planet.terraform()\n  }\n\n  class Planet {\n    func terraform(\n      atmosphereOptions: AtmosphereOptions = .default,\n      oceanOptions: OceanOptions = .default)\n    {\n      generateAtmosphere(atmosphereOptions)\n      generateOceans(oceanOptions)\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='whitespace-around-braces'\u003e\u003c/a\u003e(\u003ca href='#whitespace-around-braces'\u003elink\u003c/a\u003e) **Braces should be surrounded by a single whitespace character (either a space, or a newline) on each side.** [![SwiftFormat: spaceInsideBraces](https://img.shields.io/badge/SwiftFormat-spaceInsideBraces-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#spaceInsideBraces) [![SwiftFormat: spaceAroundBraces](https://img.shields.io/badge/SwiftFormat-spaceAroundBraces-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#spaceAroundBraces)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  struct Planet{\n    …\n  }\n\n  // WRONG\n  if condition{\n    …\n  }else{\n    …\n  }\n\n  // RIGHT\n  struct Planet {\n    …\n  }\n\n  // RIGHT\n  if condition {\n    …\n  } else {\n    …\n  }\n  ```\n\n* \u003ca id='no-spaces-around-function-parens'\u003e\u003c/a\u003e(\u003ca href='#no-spaces-around-parens'\u003elink\u003c/a\u003e) For function calls and declarations, there should be no spaces before or inside the parentheses of the argument list. [![SwiftFormat: spaceInsideParens](https://img.shields.io/badge/SwiftFormat-spaceInsideParens-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#spaceInsideParens) [![SwiftFormat: spaceAroundParens](https://img.shields.io/badge/SwiftFormat-spaceAroundParens-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#spaceAroundParens)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  func install ( _ engine: Engine ) { }\n\n  install ( AntimatterDrive( ) )\n\n  // RIGHT\n  func install(_ engine: Engine) { }\n\n  install(AntimatterDrive())\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='single-line-comments'\u003e\u003c/a\u003e(\u003ca href='#single-line-comments'\u003elink\u003c/a\u003e) **Comment blocks should use single-line comments (`//` for code comments and `///` for documentation comments)**, rather than multi-line comments (`/* ... */` and `/** ... */`). [![SwiftFormat: blockComments](https://img.shields.io/badge/SwiftFormat-blockComments-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#blockComments)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n\n  /**\n  * A planet that exists somewhere in the universe.\n  *\n  * Planets have many properties. For example, the best planets\n  * have atmospheres and bodies of water to support life.\n  */\n  class Planet {\n    /**\n      Terraforms the planet, by adding an atmosphere and ocean that is hospitable for life.\n    */\n    func terraform() {\n      /*\n      Generate the atmosphere first, before generating the ocean.\n      Otherwise, the water will just boil off immediately.\n      */\n      generateAtmosphere()\n\n      /* Now that we have an atmosphere, it's safe to generate the ocean */\n      generateOceans()\n    }\n  }\n\n  // RIGHT\n\n  /// A planet that exists somewhere in the universe.\n  ///\n  /// Planets have many properties. For example, the best planets\n  /// have atmospheres and bodies of water to support life.\n  class Planet {\n    /// Terraforms the planet, by adding an atmosphere and ocean that is hospitable for life.\n    func terraform() {\n      // Generate the atmosphere first, before generating the ocean.\n      // Otherwise, the water will just boil off immediately.\n      generateAtmosphere()\n\n      // Now that we have an atmosphere, it's safe to generate the ocean\n      generateOceans()\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='doc-comments-before-declarations'\u003e\u003c/a\u003e(\u003ca href='#doc-comments-before-declarations'\u003elink\u003c/a\u003e) **Use doc comments (`///`) instead of regular comments (`//`) before declarations within type bodies or at the top level.** [![SwiftFormat: docComments](https://img.shields.io/badge/SwiftFormat-docComments-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#docComments)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n\n  // A planet that exists somewhere in the universe.\n  class Planet {\n    // Data about the composition and density of the planet's atmosphere if present.\n    var atmosphere: Atmosphere?\n\n    // Data about the size, location, and composition of large bodies of water on the planet's surface.\n    var oceans: [Ocean]\n\n    // Terraforms the planet, by adding an atmosphere and ocean that is hospitable for life.\n    func terraform() {\n      // This gas composition has a pretty good track record so far!\n      let composition = AtmosphereComposition(nitrogen: 0.78, oxygen: 0.22)\n\n      // Generate the atmosphere first, then the oceans. Otherwise, the water will just boil off immediately.\n      generateAtmosphere(using: composition)\n      generateOceans()\n    }\n  }\n\n  // RIGHT\n\n  /// A planet that exists somewhere in the universe.\n  class Planet {\n    /// Data about the composition and density of the planet's atmosphere if present.\n    var atmosphere: Atmosphere?\n\n    /// Data about the size, location, and composition of large bodies of water on the planet's surface.\n    var oceans: [Ocean]\n\n    /// Terraforms the planet, by adding an atmosphere and ocean that is hospitable for life.\n    func terraform() {\n      // This gas composition has a pretty good track record so far!\n      let composition = AtmosphereComposition(nitrogen: 0.78, oxygen: 0.22)\n\n      // Generate the atmosphere first, then the oceans. Otherwise, the water will just boil off immediately.\n      generateAtmosphere(using: composition)\n      generateOceans()\n    }\n  }\n  \n  // ALSO RIGHT:\n\n  func terraform() {\n    /// This gas composition has a pretty good track record so far!\n    ///  - Doc comments are not required before local declarations in function scopes, but are permitted.\n    let composition = AtmosphereComposition(nitrogen: 0.78, oxygen: 0.22)\n\n    /// Generate the `atmosphere` first, **then** the `oceans`. Otherwise, the water will just boil off immediately.\n    ///  - Comments not preceding declarations can use doc comments, and will not be autocorrected into regular comments.\n    ///    This can be useful because Xcode applies markdown styling to doc comments but not regular comments.\n    generateAtmosphere(using: composition)\n    generateOceans()\n  }\n  ```\n\n  Regular comments are permitted before declarations in some cases. \n  \n  For example, comment directives like `// swiftformat:`, `// swiftlint:`, `// sourcery:`, `// MARK:` and `// TODO:` are typically required to use regular comments and don't work correctly with doc comments:\n\n  ```swift\n  // RIGHT\n\n  // swiftformat:sort\n  enum FeatureFlags {\n    case allowFasterThanLightTravel\n    case disableGravity\n    case enableDarkEnergy\n    case enableDarkMatter\n  }\n\n  // TODO: There are no more production consumers of this legacy model, so we\n  // should detangle the remaining code dependencies and clean it up.\n  struct LegacyGeocentricUniverseModel {\n    ...\n  }\n  ```\n\n  Regular comments are also allowed before a grouped block of declarations, since it's possible that the comment refers to the block as a whole rather than just the following declaration:\n\n  ```swift\n  // RIGHT\n\n  enum Planet {\n    // The inner planets\n    case mercury\n    case venus\n    case earth\n    case mars\n\n    // The outer planets\n    case jupiter\n    case saturn\n    case uranus\n    case neptune\n  }\n\n  // ALSO RIGHT\n\n  enum Planet {\n    /// The smallest planet\n    case mercury\n    case venus\n    case earth\n    case mars\n    /// The largest planet\n    case jupiter\n    case saturn\n    case uranus\n    case neptune\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='doc-comments-before-attributes'\u003e\u003c/a\u003e(\u003ca href='#doc-comments-before-attributes'\u003elink\u003c/a\u003e) **Place doc comments for a declaration before any attributes or modifiers.** [![SwiftFormat: docCommentsBeforeModifiers](https://img.shields.io/badge/SwiftFormat-docCommentsBeforeModifiers-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#docCommentsBeforeModifiers)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n\n  @MainActor\n  /// A spacecraft with everything you need to explore the universe.\n  struct Spaceship { … }\n\n  public\n  /// A spacecraft with everything you need to explore the universe.\n  struct Spaceship { … }\n\n  // RIGHT\n\n  /// A spacecraft with everything you need to explore the universe.\n  @MainActor\n  struct Spaceship { … }\n\n  /// A spacecraft with everything you need to explore the universe.\n  public struct Spaceship { … }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='whitespace-around-comment-delimiters'\u003e\u003c/a\u003e(\u003ca href='#whitespace-around-comment-delimiters'\u003elink\u003c/a\u003e) Include spaces or newlines before and after comment delimiters (`//`, `///`, `/*`, and `*/`) [![SwiftFormat: spaceAroundComments](https://img.shields.io/badge/SwiftFormat-spaceAroundComments-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#spaceAroundComments) [![SwiftFormat: spaceInsideComments](https://img.shields.io/badge/SwiftFormat-spaceInsideComments-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#spaceInsideComments)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n\n  ///A spacecraft with incredible performance characteristics\n  struct Spaceship {\n\n    func travelFasterThanLight() {/*unimplemented*/}\n\n    func travelBackInTime() { }//TODO: research whether or not this is possible\n\n  }\n\n  // RIGHT\n\n  /// A spacecraft with incredible performance characteristics\n  struct Spaceship {\n\n    func travelFasterThanLight() { /* unimplemented */ }\n\n    func travelBackInTime() { } // TODO: research whether or not this is possible\n\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='space-in-empty-braces'\u003e\u003c/a\u003e(\u003ca href='#space-in-empty-braces'\u003elink\u003c/a\u003e) Include a single space in an empty set of braces (`{ }`). [![SwiftFormat: emptyBraces](https://img.shields.io/badge/SwiftFormat-emptyBraces-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#emptyBraces)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  extension Spaceship: Trackable {}\n\n  extension SpaceshipView {\n    var accessibilityIdentifier: String {\n      get { spaceship.name }\n      set {}\n    }\n  }\n\n  // RIGHT\n  extension Spaceship: Trackable { }\n\n  extension SpaceshipView {\n    var accessibilityIdentifier: String {\n      get { spaceship.name }\n      set { }\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='prefer-for-loop-over-forEach'\u003e\u003c/a\u003e(\u003ca href='#prefer-for-loop-over-forEach'\u003elink\u003c/a\u003e) **Prefer using `for` loops over the functional `forEach(…)` method**, unless using `forEach(…)` as the last element in a functional chain. [![SwiftFormat: forLoop](https://img.shields.io/badge/SwiftFormat-forLoop-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#forLoop)\n\n  \u003cdetails\u003e\n\n  #### Why?\n  For loops are more idiomatic than the `forEach(…)` method, and are typically familiar to all developers who have experience with C-family languages. \n\n  For loops are also more expressive than the `forEach(…)` method. For loops support the `return`, `continue`, and `break` control flow keywords, while `forEach(…)` only supports `return` (which has the same behavior as `continue` in a for loop).\n  \n  ```swift\n  // WRONG\n  planets.forEach { planet in\n    planet.terraform()\n  }\n\n  // WRONG\n  planets.forEach {\n    $0.terraform()\n  }\n\n  // RIGHT\n  for planet in planets {\n    planet.terraform()\n  }\n\n  // ALSO FINE, since forEach is useful when paired with other functional methods in a chain.\n  planets\n    .filter { !$0.isGasGiant }\n    .map { PlanetTerraformer(planet: $0) }\n    .forEach { $0.terraform() }\n  ```\n    \n  \u003c/details\u003e\n\n* \u003ca id='omit-internal-keyword'\u003e\u003c/a\u003e(\u003ca href='#omit-internal-keyword'\u003elink\u003c/a\u003e) **Omit the `internal` keyword** when defining types, properties, or functions with an internal access control level. [![SwiftFormat: redundantInternal](https://img.shields.io/badge/SwiftFormat-redundantInternal-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#redundantInternal)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  internal class Spaceship {\n    internal init() { … }\n\n    internal func travel(to planet: Planet) { … }\n  }\n\n  // RIGHT, because internal access control is implied if no other access control level is specified.\n  class Spaceship {\n    init() { … }\n\n    func travel(to planet: Planet) { … }\n  }\n  ```\n\n  \u003c/details\u003e\n\n### Functions\n\n* \u003ca id='omit-function-void-return'\u003e\u003c/a\u003e(\u003ca href='#omit-function-void-return'\u003elink\u003c/a\u003e) **Omit `Void` return types from function definitions.** [![SwiftFormat: redundantVoidReturnType](https://img.shields.io/badge/SwiftFormat-redundantVoidReturnType-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#redundantVoidReturnType)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  func doSomething() -\u003e Void {\n    ...\n  }\n\n  // RIGHT\n  func doSomething() {\n    ...\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='long-function-declaration'\u003e\u003c/a\u003e(\u003ca href='#long-function-declaration'\u003elink\u003c/a\u003e) **Separate [long](https://github.com/airbnb/swift#column-width) function declarations with line breaks before each argument label, and before the return signature or any effects (`async`, `throws`).** Put the open curly brace on the next line so the first executable line doesn't look like it's another parameter. [![SwiftFormat: wrapArguments](https://img.shields.io/badge/SwiftFormat-wrapArguments-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#wrapArguments) [![SwiftFormat: braces](https://img.shields.io/badge/SwiftFormat-braces-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#braces)\n\n  \u003cdetails\u003e\n\n  ```swift\n  class Universe {\n\n    // WRONG\n    func generateStars(at location: Point, count: Int, color: StarColor, withAverageDistance averageDistance: Float) -\u003e String {\n      // This is too long and will probably auto-wrap in a weird way\n    }\n\n    // WRONG\n    func generateStars(at location: Point,\n                       count: Int,\n                       color: StarColor,\n                       withAverageDistance averageDistance: Float) -\u003e String\n    {\n      // Xcode indents all the arguments\n    }\n\n    // WRONG\n    func generateStars(\n      at location: Point,\n      count: Int,\n      color: StarColor,\n      withAverageDistance averageDistance: Float) -\u003e String {\n      populateUniverse() // this line blends in with the argument list\n    }\n\n    // WRONG\n    func generateStars(\n      at location: Point,\n      count: Int,\n      color: StarColor,\n      withAverageDistance averageDistance: Float) throws\n      -\u003e String {\n      populateUniverse() // this line blends in with the argument list\n    }\n\n    // WRONG\n    func generateStars(\n      at location: Point,\n      count: Int,\n      color: StarColor,\n      withAverageDistance averageDistance: Float) async throws // these effects are easy to miss since they're visually associated with the last parameter\n      -\u003e String\n    {\n      populateUniverse()\n    }\n\n    // RIGHT\n    func generateStars(\n      at location: Point,\n      count: Int,\n      color: StarColor,\n      withAverageDistance averageDistance: Float)\n      -\u003e String\n    {\n      populateUniverse()\n    }\n\n    // RIGHT\n    func generateStars(\n      at location: Point,\n      count: Int,\n      color: StarColor,\n      withAverageDistance averageDistance: Float)\n      async throws -\u003e String\n    {\n      populateUniverse()\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='long-function-invocation'\u003e\u003c/a\u003e(\u003ca href='#long-function-invocation'\u003elink\u003c/a\u003e) **[Long](https://github.com/airbnb/swift#column-width) function invocations should also break on each argument.** Put the closing parenthesis on the last line of the invocation. [![SwiftFormat: wrapArguments](https://img.shields.io/badge/SwiftFormat-wrapArguments-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#wrapArguments)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  universe.generateStars(at: location, count: 5, color: starColor, withAverageDistance: 4)\n\n  // WRONG\n  universe.generateStars(at: location,\n                         count: 5,\n                         color: starColor,\n                         withAverageDistance: 4)\n\n  // WRONG\n  universe.generateStars(\n    at: location,\n    count: 5,\n    color: starColor,\n    withAverageDistance: 4\n  )\n\n  // WRONG\n  universe.generate(5,\n    .stars,\n    at: location)\n\n  // RIGHT\n  universe.generateStars(\n    at: location,\n    count: 5,\n    color: starColor,\n    withAverageDistance: 4)\n\n  // RIGHT\n  universe.generate(\n    5,\n    .stars,\n    at: location)\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='unused-function-parameter-naming'\u003e\u003c/a\u003e(\u003ca href='#unused-function-parameter-naming'\u003elink\u003c/a\u003e) **Name unused function parameters as underscores (`_`).** [![SwiftFormat: unusedArguments](https://img.shields.io/badge/SwiftFormat-unusedArguments-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#unusedArguments)\n\n    \u003cdetails\u003e\n\n    #### Why?\n    Naming unused function parameters as underscores makes it more clear when the parameter is unused within the function body.\n    This can make it easier to catch subtle logical errors, and can highlight opportunities to simplify method signatures.\n\n    ```swift\n    // WRONG\n\n    // In this method, the `newCondition` parameter is unused.\n    // This is actually a logical error, and is easy to miss, but compiles without warning.\n    func updateWeather(_ newCondition: WeatherCondition) -\u003e Weather {\n      var updatedWeather = self\n      updatedWeather.condition = condition // this mistake inadvertently makes this method unable to change the weather condition\n      return updatedWeather\n    }\n\n    // In this method, the `color` parameter is unused.\n    // Is this a logical error (e.g. should it be passed through to the `universe.generateStars` method call),\n    // or is this an unused argument that should be removed from the method signature?\n    func generateUniverseWithStars(\n      at location: Point,\n      count: Int,\n      color: StarColor,\n      withAverageDistance averageDistance: Float)\n    {\n      let universe = generateUniverse()\n      universe.generateStars(\n        at: location,\n        count: count,\n        withAverageDistance: averageDistance)\n    }\n    ```\n\n    ```swift\n    // RIGHT\n\n    // Automatically reformatting the unused parameter to be an underscore\n    // makes it more clear that the parameter is unused, which makes it\n    // easier to spot the logical error.\n    func updateWeather(_: WeatherCondition) -\u003e Weather {\n      var updatedWeather = self\n      updatedWeather.condition = condition\n      return updatedWeather\n    }\n\n    // The underscore makes it more clear that the `color` parameter is unused.\n    // This method argument can either be removed if truly unnecessary,\n    // or passed through to `universe.generateStars` to correct the logical error.\n    func generateUniverseWithStars(\n      at location: Point,\n      count: Int,\n      color _: StarColor,\n      withAverageDistance averageDistance: Float)\n    {\n      let universe = generateUniverse()\n      universe.generateStars(\n        at: location,\n        count: count,\n        withAverageDistance: averageDistance)\n    }\n    ```\n\n    \u003c/details\u003e\n\n* \u003ca id='remove-blank-lines-between-chained-functions'\u003e\u003c/a\u003e(\u003ca href='#remove-blank-lines-between-chained-functions'\u003elink\u003c/a\u003e) **Remove blank lines between chained functions.** [![SwiftFormat: blanklinesbetweenchainedfunctions](https://img.shields.io/badge/SwiftFormat-blankLinesBetweenChainedFunctions-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#blanklinesbetweenchainedfunctions)\n\n  \u003cdetails\u003e\n\n  #### Why?\n\n  Improves readability and maintainability, making it easier to see the sequence of functions that are applied to the object.\n\n  ```swift\n  // WRONG\n  var innerPlanetNames: [String] {\n    planets\n      .filter { $0.isInnerPlanet }\n\n      .map { $0.name }\n  }\n\n  // WRONG\n  var innerPlanetNames: [String] {\n    planets\n      .filter { $0.isInnerPlanet }\n\n      // Gets the name of the inner planet\n      .map { $0.name }\n  }\n\n  // RIGHT\n  var innerPlanetNames: [String] {\n    planets\n      .filter { $0.isInnerPlanet }\n      .map { $0.name }\n  }\n\n  // RIGHT\n  var innerPlanetNames: [String] {\n    planets\n      .filter { $0.isInnerPlanet }\n      // Gets the name of the inner planet\n      .map { $0.name }\n  }\n  ```\n\n  \u003c/details\u003e\n\n### Closures\n\n* \u003ca id='favor-void-closure-return'\u003e\u003c/a\u003e(\u003ca href='#favor-void-closure-return'\u003elink\u003c/a\u003e) **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. [![SwiftFormat: void](https://img.shields.io/badge/SwiftFormat-void-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#void)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  func method(completion: () -\u003e ()) {\n    ...\n  }\n\n  // RIGHT\n  func method(completion: () -\u003e Void) {\n    ...\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='unused-closure-parameter-naming'\u003e\u003c/a\u003e(\u003ca href='#unused-closure-parameter-naming'\u003elink\u003c/a\u003e) **Name unused closure parameters as underscores (`_`).** [![SwiftFormat: unusedArguments](https://img.shields.io/badge/SwiftFormat-unusedArguments-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#unusedArguments)\n\n    \u003cdetails\u003e\n\n    #### Why?\n    Naming unused closure parameters as underscores reduces the cognitive overhead required to read\n    closures by making it obvious which parameters are used and which are unused.\n\n    ```swift\n    // WRONG\n    someAsyncThing() { argument1, argument2, argument3 in\n      print(argument3)\n    }\n\n    // RIGHT\n    someAsyncThing() { _, _, argument3 in\n      print(argument3)\n    }\n    ```\n\n    \u003c/details\u003e\n\n* \u003ca id='closure-brace-spacing'\u003e\u003c/a\u003e(\u003ca href='#closure-brace-spacing'\u003elink\u003c/a\u003e) **Closures should have a single space or newline inside each brace.** Trailing closures should additionally have a single space or newline outside each brace. [![SwiftFormat: spaceInsideBraces](https://img.shields.io/badge/SwiftFormat-spaceInsideBraces-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#spaceInsideBraces) [![SwiftFormat: spaceAroundBraces](https://img.shields.io/badge/SwiftFormat-spaceAroundBraces-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#spaceAroundBraces)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  let evenSquares = numbers.filter{$0.isMultiple(of: 2)}.map{  $0 * $0  }\n\n  // RIGHT\n  let evenSquares = numbers.filter { $0.isMultiple(of: 2) }.map { $0 * $0 }\n\n  // WRONG\n  let evenSquares = numbers.filter( { $0.isMultiple(of: 2) } ).map( { $0 * $0 } )\n\n  // RIGHT\n  let evenSquares = numbers.filter({ $0.isMultiple(of: 2) }).map({ $0 * $0 })\n\n  // WRONG\n  let evenSquares = numbers\n    .filter{\n      $0.isMultiple(of: 2)\n    }\n    .map{\n      $0 * $0\n    }\n\n  // RIGHT\n  let evenSquares = numbers\n    .filter {\n      $0.isMultiple(of: 2)\n    }\n    .map {\n      $0 * $0\n    }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='omit-closure-void-return'\u003e\u003c/a\u003e(\u003ca href='#omit-closure-void-return'\u003elink\u003c/a\u003e) **Omit `Void` return types from closure expressions.** [![SwiftFormat: redundantVoidReturnType](https://img.shields.io/badge/SwiftFormat-redundantVoidReturnType-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#redundantVoidReturnType)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  someAsyncThing() { argument -\u003e Void in\n    ...\n  }\n\n  // RIGHT\n  someAsyncThing() { argument in\n    ...\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='anonymous-trailing-closures'\u003e\u003c/a\u003e(\u003ca href='#anonymous-trailing-closures'\u003elink\u003c/a\u003e) **Prefer trailing closure syntax for closure arguments with no parameter name.** [![SwiftFormat: trailingClosures](https://img.shields.io/badge/SwiftFormat-trailingClosures-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#trailingClosures)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  planets.map({ $0.name })\n\n  // RIGHT\n  planets.map { $0.name }\n\n  // ALSO RIGHT, since this closure has a parameter name\n  planets.first(where: { $0.isGasGiant })\n\n  // ALSO FINE. Trailing closure syntax is still permitted for closures\n  // with parameter names. However, consider using non-trailing syntax\n  // in cases where the parameter name is semantically meaningful.\n  planets.first { $0.isGasGiant }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='unowned-captures'\u003e\u003c/a\u003e(\u003ca href='#unowned-captures'\u003elink\u003c/a\u003e) **Avoid using `unowned` captures.** Instead prefer safer alternatives like `weak` captures, or capturing variables directly. [![SwiftLint: unowned_variable_capture](https://img.shields.io/badge/SwiftLint-unowned__variable__capture-007A87.svg)](https://realm.github.io/SwiftLint/unowned_variable_capture.html)\n\n  \u003cdetails\u003e\n  `unowned` captures are unsafe because they will cause the application to crash if the referenced object has been deallocated.\n\n  ```swift\n  // WRONG: Crashes if `self` has been deallocated when closures are called.\n  final class SpaceshipNavigationService {\n    let spaceship: Spaceship\n    let planet: Planet\n    \n    func colonizePlanet() {\n      spaceship.travel(to: planet, onArrival: { [unowned self] in\n        planet.colonize()\n      })\n    }\n    \n    func exploreSystem() {\n      spaceship.travel(to: planet, nextDestination: { [unowned self] in\n        planet.moons?.first\n      })\n    }\n  }\n  ```\n\n  `weak` captures are safer because they require the author to explicitly handle the case where the referenced object no longer exists.\n\n  ```swift\n  // RIGHT: Uses a `weak self` capture and explicitly handles the case where `self` has been deallocated\n  final class SpaceshipNavigationService {\n    let spaceship: Spaceship\n    let planet: Planet\n    \n    func colonizePlanet() {\n      spaceship.travel(to: planet, onArrival: { [weak self] in\n        guard let self else { return }\n        planet.colonize()\n      })\n    }\n    \n    func exploreSystem() {\n      spaceship.travel(to: planet, nextDestination: { [weak self] in\n        guard let self else { return nil }\n        return planet.moons?.first\n      })\n    }\n  }\n  ```\n\n  Alternatively, consider directly capturing the variables that are used in the closure. This lets you avoid having to handle the case where `self` is nil, since you don't even need to reference `self`:\n\n  ```swift\n  // RIGHT: Explicitly captures `planet` instead of capturing `self`\n  final class SpaceshipNavigationService {\n    let spaceship: Spaceship\n    let planet: Planet\n    \n    func colonizePlanet() {\n      spaceship.travel(to: planet, onArrival: { [planet] in\n        planet.colonize()\n      })\n    }\n    \n    func exploreSystem() {\n      spaceship.travel(to: planet, nextDestination: { [planet] in\n        planet.moons?.first\n      })\n    }\n  }\n  ```\n  \n  \u003c/details\u003e\n\n### Operators\n\n* \u003ca id='infix-operator-spacing'\u003e\u003c/a\u003e(\u003ca href='#infix-operator-spacing'\u003elink\u003c/a\u003e) **Infix operators should have a single space on either side.** However, in operator definitions, omit the trailing space between the operator and the open parenthesis. This rule does not apply to range operators (e.g. `1...3`). [![SwiftFormat: spaceAroundOperators](https://img.shields.io/badge/SwiftFormat-spaceAroundOperators-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#spacearoundoperators)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  let capacity = 1+2\n  let capacity = currentCapacity??0\n  let capacity=newCapacity\n  let latitude = region.center.latitude-region.span.latitudeDelta/2.0\n\n  // RIGHT\n  let capacity = 1 + 2\n  let capacity = currentCapacity ?? 0\n  let capacity = newCapacity\n  let latitude = region.center.latitude - region.span.latitudeDelta / 2.0\n  ```\n\n  ```swift\n  // WRONG\n  static func == (_ lhs: MyView, _ rhs: MyView) -\u003e Bool {\n    lhs.id == rhs.id\n  }\n\n  // RIGHT\n  static func ==(_ lhs: MyView, _ rhs: MyView) -\u003e Bool {\n    lhs.id == rhs.id\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='long-ternary-operator-expressions'\u003e\u003c/a\u003e(\u003ca href='#long-ternary-operator-expressions'\u003elink\u003c/a\u003e) **[Long](https://github.com/airbnb/swift#column-width) ternary operator expressions should wrap before the `?` and before the `:`**, putting each conditional branch on a separate line. [![SwiftFormat: wrap](https://img.shields.io/badge/SwiftFormat-wrap-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#wrap)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG (too long)\n  let destinationPlanet = solarSystem.hasPlanetsInHabitableZone ? solarSystem.planetsInHabitableZone.first : solarSystem.uninhabitablePlanets.first\n\n  // WRONG (naive wrapping)\n  let destinationPlanet = solarSystem.hasPlanetsInHabitableZone ? solarSystem.planetsInHabitableZone.first :\n    solarSystem.uninhabitablePlanets.first\n\n  // WRONG (unbalanced operators)\n  let destinationPlanet = solarSystem.hasPlanetsInHabitableZone ?\n    solarSystem.planetsInHabitableZone.first :\n    solarSystem.uninhabitablePlanets.first\n\n  // RIGHT\n  let destinationPlanet = solarSystem.hasPlanetsInHabitableZone\n    ? solarSystem.planetsInHabitableZone.first\n    : solarSystem.uninhabitablePlanets.first\n   ```\n\n  \u003c/details\u003e\n\n* \u003ca id='use-commas-in-and-conditions'\u003e\u003c/a\u003e(\u003ca href='#use-commas-in-and-conditions'\u003elink\u003c/a\u003e) In conditional statements (`if`, `guard`, `while`), separate boolean conditions using commas (`,`) instead of `\u0026\u0026` operators.  [![SwiftFormat: andOperator](https://img.shields.io/badge/SwiftFormat-andOperator-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#andOperator)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  if let star = planet.star, !planet.isHabitable \u0026\u0026 planet.isInHabitableZone(of: star) {\n    planet.terraform()\n  }\n\n  if\n    let star = planet.star,\n    !planet.isHabitable\n    \u0026\u0026 planet.isInHabitableZone(of: star)\n  {\n    planet.terraform()\n  }\n\n  // RIGHT\n  if let star = planet.star, !planet.isHabitable, planet.isInHabitableZone(of: star) {\n    planet.terraform()\n  }\n\n  if\n    let star = planet.star,\n    !planet.isHabitable,\n    planet.isInHabitableZone(of: star)\n  {\n    planet.terraform()\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='prefer-bound-generic-extension-shorthand'\u003e\u003c/a\u003e(\u003ca href='#prefer-bound-generic-extension-shorthand'\u003elink\u003c/a\u003e) When extending bound generic types, prefer using generic bracket syntax (`extension Collection\u003cPlanet\u003e`), or sugared syntax for applicable standard library types (`extension [Planet]`) instead of generic type constraints. [![SwiftFormat: genericExtensions](https://img.shields.io/badge/SwiftFormat-genericExtensions-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#genericExtensions)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  extension Array where Element == Star { … }\n  extension Optional where Wrapped == Spaceship { … }\n  extension Dictionary where Key == Moon, Element == Planet { … }\n  extension Collection where Element == Universe { … }\n  extension StateStore where State == SpaceshipState, Action == SpaceshipAction { … }\n\n  // RIGHT\n  extension [Star] { … }\n  extension Spaceship? { … }\n  extension [Moon: Planet] { … }\n  extension Collection\u003cUniverse\u003e { … }\n  extension StateStore\u003cSpaceshipState, SpaceshipAction\u003e { … }\n\n  // ALSO RIGHT. There are multiple types that could satisfy this constraint\n  // (e.g. [Planet], [Moon]), so this is not a \"bound generic type\" and isn't\n  // eligible for the generic bracket syntax.\n  extension Array where Element: PlanetaryBody { }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='no-semicolons'\u003e\u003c/a\u003e(\u003ca href='#no-semicolons'\u003elink\u003c/a\u003e) **Avoid using semicolons.** Semicolons are not required at the end of a line, so should be omitted. While you can use semicolons to place two statements on the same line, it is more common and preferred to separate them using a newline instead. [![SwiftFormat: semicolons](https://img.shields.io/badge/SwiftFormat-semicolons-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#semicolons)\n\n  \u003cdetails\u003e\n\n  ### Examples\n\n  ```swift\n  // WRONG. Semicolons are not required and can be omitted.\n  let mercury = planets[0];\n  let venus = planets[1];\n  let earth = planets[2];\n\n  // WRONG. While you can use semicolons to place multiple statements on a single line,\n  // it is more common and preferred to separate them using newlines instead.\n  let mercury = planets[0]; let venus = planets[1]; let earth = planets[2];\n\n  // RIGHT\n  let mercury = planets[0]\n  let venus = planets[1]\n  let earth = planets[2]\n\n  // WRONG\n  guard let moon = planet.moon else { completion(nil); return }\n\n  // WRONG\n  guard let moon = planet.moon else { \n    completion(nil); return\n  }\n\n  // RIGHT\n  guard let moon = planet.moon else { \n    completion(nil)\n    return\n  }\n  ```\n\n  \u003c/details\u003e\n\n**[⬆ back to top](#table-of-contents)**\n\n## Patterns\n\n* \u003ca id='implicitly-unwrapped-optionals'\u003e\u003c/a\u003e(\u003ca href='#implicitly-unwrapped-optionals'\u003elink\u003c/a\u003e) **Prefer initializing properties at `init` time whenever possible, rather than using implicitly unwrapped optionals.**  A notable exception is UIViewController's `view` property. [![SwiftLint: implicitly_unwrapped_optional](https://img.shields.io/badge/SwiftLint-implicitly__unwrapped__optional-007A87.svg)](https://realm.github.io/SwiftLint/implicitly_unwrapped_optional)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  class MyClass {\n\n    init() {\n      super.init()\n      someValue = 5\n    }\n\n    var someValue: Int!\n  }\n\n  // RIGHT\n  class MyClass {\n\n    init() {\n      someValue = 0\n      super.init()\n    }\n\n    var someValue: Int\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='time-intensive-init'\u003e\u003c/a\u003e(\u003ca href='#time-intensive-init'\u003elink\u003c/a\u003e) **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.\n\n* \u003ca id='complex-property-observers'\u003e\u003c/a\u003e(\u003ca href='#complex-property-observers'\u003elink\u003c/a\u003e) **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.\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  class TextField {\n    var text: String? {\n      didSet {\n        guard oldValue != text else {\n          return\n        }\n\n        // Do a bunch of text-related side-effects.\n      }\n    }\n  }\n\n  // RIGHT\n  class TextField {\n    var text: String? {\n      didSet { textDidUpdate(from: oldValue) }\n    }\n\n    private func textDidUpdate(from oldValue: String?) {\n      guard oldValue != text else {\n        return\n      }\n\n      // Do a bunch of text-related side-effects.\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='complex-callback-block'\u003e\u003c/a\u003e(\u003ca href='#complex-callback-block'\u003elink\u003c/a\u003e) **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.\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  class MyClass {\n\n    func request(completion: () -\u003e Void) {\n      API.request() { [weak self] response in\n        if let self {\n          // Processing and side effects\n        }\n        completion()\n      }\n    }\n  }\n\n  // RIGHT\n  class MyClass {\n\n    func request(completion: () -\u003e Void) {\n      API.request() { [weak self] response in\n        guard let self else { return }\n        self.doSomething(with: self.property, response: response)\n        completion()\n      }\n    }\n\n    func doSomething(with nonOptionalParameter: SomeClass, response: SomeResponseClass) {\n      // Processing and side effects\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='guards-at-top'\u003e\u003c/a\u003e(\u003ca href='#guards-at-top'\u003elink\u003c/a\u003e) **Prefer using `guard` at the beginning of a scope.**\n\n  \u003cdetails\u003e\n\n  #### Why?\n  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.\n\n  \u003c/details\u003e\n\n* \u003ca id='limit-access-control'\u003e\u003c/a\u003e(\u003ca href='#limit-access-control'\u003elink\u003c/a\u003e) **Access control should be at the strictest level possible.** Prefer `public` to `open` and `private` to `fileprivate` unless you need that behavior. [![SwiftFormat: redundantFileprivate](https://img.shields.io/badge/SwiftFormat-redundantFileprivate-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#redundantFileprivate)\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  public struct Spaceship {\n    // WRONG: `engine` is used in `extension Spaceship` below,\n    // but extensions in the same file can access `private` members.\n    fileprivate let engine: AntimatterEngine\n\n    // WRONG: `hull` is not used by any other type, so `fileprivate` is unnecessary.\n    fileprivate let hull: Hull\n\n    // RIGHT: `navigation` is used in `extension Pilot` below,\n    // so `fileprivate` is necessary here.\n    fileprivate let navigation: SpecialRelativityNavigationService\n  }\n\n  extension Spaceship {\n    public func blastOff() {\n      engine.start()\n    }\n  }\n\n  extension Pilot {\n    public func chartCourse() {\n      spaceship.navigation.course = .andromedaGalaxy\n      spaceship.blastOff()\n    }\n  }\n  ```\n\n  ```swift\n  // RIGHT\n  public struct Spaceship {\n    fileprivate let navigation: SpecialRelativityNavigationService\n    private let engine: AntimatterEngine\n    private let hull: Hull\n  }\n\n  extension Spaceship {\n    public func blastOff() {\n      engine.start()\n    }\n  }\n\n  extension Pilot {\n    public func chartCourse() {\n      spaceship.navigation.course = .andromedaGalaxy\n      spaceship.blastOff()\n    }\n  }\n  ```\n\n* \u003ca id='avoid-global-functions'\u003e\u003c/a\u003e(\u003ca href='#avoid-global-functions'\u003elink\u003c/a\u003e) **Avoid global functions whenever possible.** Prefer methods within type definitions.\n\n  \u003cdetails\u003e\n\n  ```swift\n  // WRONG\n  func age(of person: Person, bornAt: TimeInterval) -\u003e Int {\n    // ...\n  }\n\n  func jump(person: Person) {\n    // ...\n  }\n\n  // RIGHT\n  class Person {\n    var bornAt: TimeInterval\n\n    var age: Int {\n      // ...\n    }\n\n    func jump() {\n      // ...\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='namespace-using-enums'\u003e\u003c/a\u003e(\u003ca href='#namespace-using-enums'\u003elink\u003c/a\u003e) **Use caseless `enum`s for organizing `public` or `internal` constants and functions into namespaces.** [![SwiftFormat: enumNamespaces](https://img.shields.io/badge/SwiftFormat-enumNamespaces-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#enumNamespaces)\n  * Avoid creating non-namespaced global constants and functions.\n  * Feel free to nest namespaces where it adds clarity.\n  * `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.\n\n  \u003cdetails\u003e\n\n  #### Why?\n  Caseless `enum`s work well as namespaces because they cannot be instantiated, which matches their intent.\n\n  ```swift\n  // WRONG\n  struct Environment {\n    static let earthGravity = 9.8\n    static let moonGravity = 1.6\n  }\n\n  // WRONG\n  struct Environment {\n\n    struct Earth {\n      static let gravity = 9.8\n    }\n\n    struct Moon {\n      static let gravity = 1.6\n    }\n  }\n\n  // RIGHT\n  enum Environment {\n\n    enum Earth {\n      static let gravity = 9.8\n    }\n\n    enum Moon {\n      static let gravity = 1.6\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='auto-enum-values'\u003e\u003c/a\u003e(\u003ca href='#auto-enum-values'\u003elink\u003c/a\u003e) **Use Swift's automatic enum values unless they map to an external source.** Add a comment explaining why explicit values are defined. [![SwiftFormat: redundantRawValues](https://img.shields.io/badge/SwiftFormat-redundantRawValues-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/main/Rules.md#redundantRawValues)\n\n  \u003cdetails\u003e\n\n  #### Why?\n  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 explicitly, and document what these values are mapping to.\n\n  This ensures that if someone adds a new value in the middle, they won't accidentally break things.\n\n  ```swift\n  // WRONG\n  enum ErrorType: String {\n    case error = \"error\"\n    case warning = \"warning\"\n  }\n\n  // WRONG\n  enum UserType: String {\n    case owner\n    case manager\n    case member\n  }\n\n  // WRONG\n  enum Planet: Int {\n    case mercury = 0\n    case venus = 1\n    case earth = 2\n    case mars = 3\n    case jupiter = 4\n    case saturn = 5\n    case uranus = 6\n    case neptune = 7\n  }\n\n  // WRONG\n  enum ErrorCode: Int {\n    case notEnoughMemory\n    case invalidResource\n    case timeOut\n  }\n\n  // RIGHT\n  // Relying on Swift's automatic enum values\n  enum ErrorType: String {\n    case error\n    case warning\n  }\n\n  // RIGHT\n  /// These are written to a logging service. Explicit values ensure they're consistent across binaries.\n  // swiftformat:disable redundantRawValues\n  enum UserType: String {\n    case owner = \"owner\"\n    case manager = \"manager\"\n    case member = \"member\"\n  }\n  // swiftformat:enable redundantRawValues\n\n  // RIGHT\n  // Relying on Swift's automatic enum values\n  enum Planet: Int {\n    case mercury\n    case venus\n    case earth\n    case mars\n    case jupiter\n    case saturn\n    case uranus\n    case neptune\n  }\n\n  // RIGHT\n  /// These values come from the server, so we set them here explicitly to match those values.\n  enum ErrorCode: Int {\n    case notEnoughMemory = 0\n    case invalidResource = 1\n    case timeOut = 2\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='semantic-optionals'\u003e\u003c/a\u003e(\u003ca href='#semantic-optionals'\u003elink\u003c/a\u003e) **Use optionals only when they have semantic meaning.**\n\n* \u003ca id='prefer-immutable-values'\u003e\u003c/a\u003e(\u003ca href='#prefer-immutable-values'\u003elink\u003c/a\u003e) **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.\n\n  \u003cdetails\u003e\n\n  #### Why?\n  Mutable variables increase complexity, so try to keep them in as narrow a scope as possible.\n\n  ```swift\n  // WRONG\n  var results = [SomeType]()\n  for element in input {\n    let result = transform(element)\n    results.append(result)\n  }\n\n  // RIGHT\n  let results = input.map { transform($0) }\n  ```\n\n  ```swift\n  // WRONG\n  var results = [SomeType]()\n  for element in input {\n    if let result = transformThatReturnsAnOptional(element) {\n      results.append(result)\n    }\n  }\n\n  // RIGHT\n  let results = input.compactMap { transformThatReturnsAnOptional($0) }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='prefer-immutable-statics'\u003e\u003c/a\u003e(\u003ca href='#prefer-immutable-statics'\u003elink\u003c/a\u003e) **Prefer immutable or computed static properties over mutable ones whenever possible.** Use stored `static let` properties or computed `static var` properties over stored `static var` properties whenever possible, as stored `static var` properties are global mutable state.\n\n  \u003cdetails\u003e\n\n  #### Why?\n  Global mutable state increases complexity and makes it harder to reason about the behavior of applications. It should be avoided when possible.\n\n  ```swift\n  // WRONG\n  enum Fonts {\n    static var title = UIFont(…)\n  }\n\n  // RIGHT\n  enum Fonts {\n    static let title = UIFont(…)\n  }\n  ```\n\n  ```swift\n  // WRONG\n  struct FeatureState {\n    var count: Int\n\n    static var initial = FeatureState(count: 0)\n  }\n\n  // RIGHT\n  struct FeatureState {\n    var count: Int\n\n    static var initial: FeatureState {\n      // Vend static properties that are cheap to compute\n      FeatureState(count: 0)\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='preconditions-and-asserts'\u003e\u003c/a\u003e(\u003ca href='#preconditions-and-asserts'\u003elink\u003c/a\u003e) **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. [![SwiftLint: fatal_error_message](https://img.shields.io/badge/SwiftLint-fatal__error__message-007A87.svg)](https://realm.github.io/SwiftLint/fatal_error_message)\n\n  \u003cdetails\u003e\n\n  ```swift\n  func didSubmitText(_ text: String) {\n    // It's unclear how this was called with an empty string; our custom text field shouldn't allow this.\n    // This assert is useful for debugging but it's OK if we simply ignore this scenario in production.\n    guard !text.isEmpty else {\n      assertionFailure(\"Unexpected empty string\")\n      return\n    }\n    // ...\n  }\n\n  func transformedItem(atIndex index: Int, from items: [Item]) -\u003e Item {\n    precondition(index \u003e= 0 \u0026\u0026 index \u003c items.count)\n    // It's impossible to continue executing if the precondition has failed.\n    // ...\n  }\n\n  func makeImage(name: String) -\u003e UIImage {\n    guard let image = UIImage(named: name, in: nil, compatibleWith: nil) else {\n      fatalError(\"Image named \\(name) couldn't be loaded.\")\n      // We want the error message so we know the name of the missing image.\n    }\n    return image\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='static-type-methods-by-default'\u003e\u003c/a\u003e(\u003ca href='#static-type-methods-by-default'\u003elink\u003c/a\u003e) **Default type methods to `static`.**\n\n  \u003cdetails\u003e\n\n  #### Why?\n  If a method needs to be overridden, the author should opt into that functionality by using the `class` keyword instead.\n\n  ```swift\n  // WRONG\n  class Fruit {\n    class func eatFruits(_ fruits: [Fruit]) { ... }\n  }\n\n  // RIGHT\n  class Fruit {\n    static func eatFruits(_ fruits: [Fruit]) { ... }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='final-classes-by-default'\u003e\u003c/a\u003e(\u003ca href='#final-classes-by-default'\u003elink\u003c/a\u003e) **Default classes to `final`.**\n\n  \u003cdetails\u003e\n\n  #### Why?\n  If a class needs to be overridden, the author should opt into that functionality by omitting the `final` keyword.\n\n  ```swift\n  // WRONG\n  class SettingsRepository {\n    // ...\n  }\n\n  // RIGHT\n  final class SettingsRepository {\n    // ...\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='switch-avoid-default'\u003e\u003c/a\u003e(\u003ca href='#switch-avoid-default'\u003elink\u003c/a\u003e) When switching over an enum, generally prefer enumerating all cases rather than using the `default` case.\n\n  \u003cdetails\u003e\n\n  #### Why?\n  Enumerating every case requires developers and reviewers have to consider the correctness of every switch statement when new cases are added in the future.\n\n  ```swift\n  // NOT PREFERRED\n  switch trafficLight {\n  case .greenLight:\n    // Move your vehicle\n  default:\n    // Stop your vehicle\n  }\n\n  // PREFERRED\n  switch trafficLight {\n  case .greenLight:\n    // Move your vehicle\n  case .yellowLight, .redLight:\n    // Stop your vehicle\n  }\n  \n  // COUNTEREXAMPLES\n\n  enum TaskState {\n    case pending\n    case running\n    case canceling\n    case success(Success)\n    case failure(Error)\n\n    // We expect that this property will remain valid if additional cases are added to the enumeration.\n    public var isRunning: Bool {\n      switch self {\n      case .running:\n        true\n      default:\n        false\n      }\n    }  \n  }\n\n  extension TaskState: Equatable {\n    // Explicitly listing each state would be too burdensome. Ideally this function could be implemented with a well-tested macro.\n    public static func == (lhs: TaskState, rhs: TaskState) -\u003e Bool {\n      switch (lhs, rhs) {\n      case (.pending, .pending):\n        true\n      case (.running, .running):\n        true\n      case (.canceling, .canceling):\n        true\n      case (.success(let lhs), .success(let rhs)):\n        lhs == rhs\n      case (.failure(let lhs), .failure(let rhs)):\n        lhs == rhs\n      default:\n        false\n      }\n    }\n  }\n  ```\n\n  \u003c/details\u003e\n\n* \u003ca id='optional-nil-check'\u003e\u003c/a\u003e(\u003ca href='#optional-nil-check'\u003elink\u003c/a\u003e) **Check for nil rather than using optional binding if you don't need to ","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fairbnb%2Fswift","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fairbnb%2Fswift","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fairbnb%2Fswift/lists"}