Suche…


Bemerkungen

Swift hat einen offiziellen Style Guide: Swift.org API Design Guidelines . Ein weiterer beliebter Leitfaden ist The Official raywenderlich.com Swift Style Guide.

Nutzung löschen

Mehrdeutigkeit vermeiden

Der Name von Klassen, Strukturen, Funktionen und Variablen sollte Mehrdeutigkeiten vermeiden.

Beispiel:

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

Der Funktionsaufruf für diese Funktion sieht dann so aus:

list.remove(at: 42)

Auf diese Weise werden Mehrdeutigkeiten vermieden. Wenn der Funktionsaufruf nur list.remove(42) wäre, wäre es unklar, ob ein Element mit dem list.remove(42) entfernt würde oder ob das Element am Index 42 entfernt würde.


Vermeiden Sie Redundanz

Der Name der Funktionen sollte keine redundanten Informationen enthalten.

Ein schlechtes Beispiel wäre:

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

Ein Aufruf der Funktion kann wie list.removeElement(someObject) aussehen. Die Variable someObject bereits an, dass ein Element entfernt wird. Es wäre besser, wenn die Funktionssignatur so aussieht:

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

Der Aufruf dieser Funktion sieht folgendermaßen aus: list.remove(someObject) .


Benennen von Variablen nach ihrer Rolle

Variablen sollten nach ihrer Rolle (z. B. Lieferant, Begrüßung) anstelle ihres Typs (z. B. Fabrik, Zeichenfolge usw.) benannt werden.

Hohe Kopplung zwischen Protokollnamen und Variablennamen

Wenn der Name des Typs in den meisten Fällen seine Rolle beschreibt (zB Iterator), sollte der Typ mit dem Suffix `Type` benannt werden. (zB IteratorType)

Geben Sie zusätzliche Details an, wenn Sie schwach typisierte Parameter verwenden

Wenn der Typ eines Objekts seine Verwendung in einem Funktionsaufruf nicht eindeutig anzeigt, sollte die Funktion mit einem vorangestellten Hauptwort für jeden schwach typisierten Parameter benannt werden, der seine Verwendung beschreibt.
Beispiel:
func addObserver(_ observer: NSObject, forKeyPath path: String)

für den ein Aufruf aussehen würde wie: object.addObserver (self, forKeyPath: path)

anstatt

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

zu der ein Aufruf wie object.add(self, for: path) aussehen würde

Fließende Verwendung

Natürliche Sprache verwenden

Funktionsaufrufe sollten der natürlichen englischen Sprache nahekommen.

Beispiel:

list.insert(element, at: index) 

anstatt

list.insert(element, position: index)

Benennen von Factory-Methoden

Factory-Methoden sollten mit dem Präfix "make" beginnen.

Beispiel:

factory.makeObject()

Benennungsparameter in Initialisierern und Factory-Methoden

Der Name des ersten Arguments sollte nicht in die Benennung einer Factory-Methode oder eines Initialisierers einbezogen werden.

Beispiel:

factory.makeObject(key: value)

Anstatt:

factory.makeObject(havingProperty: value)

Benennung nach Nebenwirkungen

  • Funktionen mit Nebenwirkungen (mutierende Funktionen) sollten mit Verben oder Substantiven benannt werden, denen form- vorangestellt form- .
  • Funktionen ohne Nebenwirkungen (nicht mutierende Funktionen) sollten mit Substantiven oder Verben mit dem Suffix -ing oder -ed .
Beispiel: Funktionen verändern:
print(value)
array.sort()                 // in place sorting
list.add(value)              // mutates list
set.formUnion(anotherSet)    // set is now the union of set and anotherSet

Nicht mutierende Funktionen:

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

Boolesche Funktionen oder Variablen

Anweisungen, die Boolean enthalten, sollten als Aussagen gelesen werden.

Beispiel:

set.isEmpty
line.intersects(anotherLine)

Protokolle benennen

  • Protokolle, die beschreiben, was etwas ist, sollten mit Substantiven benannt werden.
  • Protokolle, die die Fähigkeiten beschreiben, sollten -able , -ible oder -ing als Suffix haben.
Beispiel:
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

Typen und Eigenschaften

Typen, Variablen und Eigenschaften sollten als Substantive gelesen werden.

Beispiel:

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

Kapitalisierung

Typen und Protokolle

Typ- und Protokollnamen sollten mit einem Großbuchstaben beginnen.

Beispiel:

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

Alles andere...

Variablen, Konstanten, Funktionen und Aufzählungsfälle sollten mit einem Kleinbuchstaben beginnen.

Beispiel:

let greeting = "Hello"
let height = 42.0

enum Color {
    case red
    case green
    case blue
}

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

Kamel Fall:

Bei allen Benennungen sollte der entsprechende Kamelfall verwendet werden. Oberes Kamelgehäuse für Typ- / Protokollnamen und unteres Kamelgehäuse für alles andere.

Oberes Kamelgehäuse:

protocol IteratorType { ... }

Untere Kamelhülle:

let inputView = ...

Abkürzungen

Abkürzungen sollten vermieden werden, es sei denn, sie werden häufig verwendet (z. B. URL, ID). Wenn eine Abkürzung verwendet wird, sollten alle Buchstaben den gleichen Fall haben.

Beispiel:

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


Modified text is an extract of the original Stack Overflow Documentation
Lizenziert unter CC BY-SA 3.0
Nicht angeschlossen an Stack Overflow