Sök…


Anmärkningar

Swift har en officiell stilguide: Swift.org API-riktlinjer för design . En annan populär guide är The Official raywenderlich.com Swift Style Guide.

Tydlig användning

Undvik tvetydighet

Namnet på klasser, strukturer, funktioner och variabler bör undvika tvetydighet.

Exempel:

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

Funktionsanropet till den här funktionen kommer då att se ut så här:

list.remove(at: 42)

På detta sätt undviks tvetydighet. Om funktionssamtalet bara skulle vara list.remove(42) skulle det vara oklart, om ett element lika med 42 skulle tas bort eller om elementet vid index 42 skulle tas bort.


Undvik redundans

Namnet på funktioner bör inte innehålla redundant information.

Ett dåligt exempel skulle vara:

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

Ett samtal till funktionen kan se ut som list.removeElement(someObject) . Variabeln someObject indikerar redan att ett element tas bort. Det skulle vara bättre att funktionssignaturen ser ut så här:

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

Samtalet till den här funktionen ser ut så här: list.remove(someObject) .


Namnge variabler efter deras roll

Variabler bör namnges efter deras roll (t.ex. leverantör, hälsning) istället för deras typ (t.ex. fabrik, sträng osv.)

Hög koppling mellan protokollnamn och variabla namn

Om namnet på typen beskriver sin roll i de flesta fall (t.ex. Iterator), ska typen benämnas med suffixet "Type". (t.ex. IteratorType)

Ange ytterligare information när du använder svagt skrivna parametrar

Om typen av ett objekt inte anger dess användning i ett funktionssamtal tydligt, bör funktionen namnges med ett föregående substantiv för varje svagt typad parameter, som beskriver dess användning.
Exempel:
func addObserver(_ observer: NSObject, forKeyPath path: String)

till vilket ett samtal skulle se ut som `object.addObserver (self, forKeyPath: path)

istället för

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

till vilket ett samtal skulle se ut som object.add(self, for: path)

Flytande användning

Använda naturligt språk

Funktionssamtal bör vara nära det naturliga engelska språket.

Exempel:

list.insert(element, at: index) 

istället för

list.insert(element, position: index)

Namnge fabriksmetoder

Fabriksmetoder bör börja med prefixet "fabrikat".

Exempel:

factory.makeObject()

Namnge parametrar i initierare och fabriksmetoder

Namnet på det första argumentet bör inte vara involverat i att namnge en fabriksmetod eller initialisering.

Exempel:

factory.makeObject(key: value)

Istället för:

factory.makeObject(havingProperty: value)

Namnge efter biverkningar

  • Funktioner med biverkningar (mutationsfunktioner) ska namnges med hjälp av verb eller substantiv förformade med form- .
  • Funktioner utan biverkningar (icke-muterande funktioner) ska namnges med hjälp av substantiv eller verb med suffix -ing eller -ed .
Exempel: Muterande funktioner:
print(value)
array.sort()                 // in place sorting
list.add(value)              // mutates list
set.formUnion(anotherSet)    // set is now the union of set and anotherSet

Icke-muterande funktioner:

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

Booleska funktioner eller variabler

Uttalanden som involverar booleaner bör läsa som påståenden.

Exempel:

set.isEmpty
line.intersects(anotherLine)

Namnge protokoll

  • Protokoll som beskriver vad något är bör namnges med substantiv.
  • Protokoll som beskriver kapaciteter bör ha -able , -ible eller -ing som efterlikning.
Exempel:
Collection        // describes that something is a collection
ProgressReporting // describes that something has the capability of reporting progress
Equatable         // describes that something has the capability of being equal to something

Typer och egenskaper

Typer, variabler och egenskaper bör läsas som substantiv.

Exempel:

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

Kapitalisering

Typer och protokoll

Typ- och protokollnamn bör börja med en stor bokstav.

Exempel:

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

Allt annat...

Variabler, konstanter, funktioner och uppräkningsfall bör börja med en liten bokstav.

Exempel:

let greeting = "Hello"
let height = 42.0

enum Color {
    case red
    case green
    case blue
}

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

Camel Case:

Alla namngivning bör använda lämpligt kamelväska. Övre kamelväska för typ / protokollnamn och undre kamelväska för allt annat.

Övre kamelfodral:

protocol IteratorType { ... }

Lägre kamelfall:

let inputView = ...

förkortningar

Förkortningar bör undvikas om de inte används ofta (t.ex. URL, ID). Om en förkortning används ska alla bokstäver ha samma sak.

Exempel:

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


Modified text is an extract of the original Stack Overflow Documentation
Licensierat under CC BY-SA 3.0
Inte anslutet till Stack Overflow