Ricerca…


Osservazioni

Swift ha una guida di stile ufficiale: Swift.org API Design Guidelines . Un'altra guida popolare è The Official raywenderlich.com Swift Style Guide.

Cancella uso

Evita l'ambiguità

Il nome di classi, strutture, funzioni e variabili dovrebbe evitare l'ambiguità.

Esempio:

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

La chiamata di funzione a questa funzione sarà quindi simile a questa:

list.remove(at: 42)

In questo modo, si evita l'ambiguità. Se la chiamata alla funzione fosse solo list.remove(42) non sarebbe chiaro se un Elemento pari a 42 fosse rimosso o se l'Elemento nell'Indice 42 fosse rimosso.


Evitare ridondanza

Il nome delle funzioni non dovrebbe contenere informazioni ridondanti.

Un cattivo esempio potrebbe essere:

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

Una chiamata alla funzione può apparire come list.removeElement(someObject) . La variabile someObject indica già che un elemento viene rimosso. Sarebbe meglio che la firma della funzione assomigli a questo:

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

La chiamata a questa funzione è la seguente: list.remove(someObject) .


Denominazione delle variabili in base al loro ruolo

Le variabili dovrebbero essere nominate in base al loro ruolo (ad esempio fornitore, saluto) al posto del loro tipo (ad es. Fabbrica, stringa, ecc.)

Elevato accoppiamento tra nome protocollo e nomi variabili

Se il nome del tipo descrive il suo ruolo nella maggior parte dei casi (es. Iterator), il tipo dovrebbe essere nominato con il suffisso `Type`. (ad es. IteratorType)

Fornire ulteriori dettagli quando si utilizzano parametri debolmente tipizzati

Se il tipo di un oggetto non indica chiaramente il suo utilizzo in una chiamata di funzione, la funzione deve essere denominata con un nome precedente per ogni parametro debolmente digitato, descrivendone l'utilizzo.
Esempio:
func addObserver(_ observer: NSObject, forKeyPath path: String)

a cui apparirebbe una chiamata `object.addObserver (self, forKeyPath: path)

invece di

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

a cui una chiamata sembrerebbe object.add(self, for: path)

Utilizzo fluido

Usando il linguaggio naturale

Le chiamate di funzioni dovrebbero essere vicine alla naturale lingua inglese.

Esempio:

list.insert(element, at: index) 

invece di

list.insert(element, position: index)

Denominazione dei metodi di fabbrica

I metodi di fabbrica dovrebbero iniziare con il prefisso `make`.

Esempio:

factory.makeObject()

Denominazione dei parametri negli inizializzatori e nei metodi di fabbrica

Il nome del primo argomento non dovrebbe essere coinvolto nel nominare un metodo factory o un inizializzatore.

Esempio:

factory.makeObject(key: value)

Invece di:

factory.makeObject(havingProperty: value)

Denominazione in base agli effetti collaterali

  • Le funzioni con effetti collaterali (funzioni mutanti) dovrebbero essere denominate usando verbi o nomi preceduti da form- .
  • Le funzioni senza effetti collaterali (funzioni nonmutating) dovrebbero essere denominate usando nomi o verbi con suffisso -ing o -ed .
Esempio: funzioni di muting:
print(value)
array.sort()                 // in place sorting
list.add(value)              // mutates list
set.formUnion(anotherSet)    // set is now the union of set and anotherSet

Funzioni di nonmutating:

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

Funzioni o variabili booleane

Le dichiarazioni che coinvolgono i booleani dovrebbero essere lette come affermazioni.

Esempio:

set.isEmpty
line.intersects(anotherLine)

Protocolli di denominazione

  • I protocolli che descrivono cosa dovrebbe essere chiamato con nomi.
  • I protocolli che descrivono le funzionalità dovrebbero avere -able , -ible o -ing come suffisso.
Esempio:
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

Tipi e proprietà

Tipi, variabili e proprietà dovrebbero essere letti come nomi.

Esempio:

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

capitalizzazione

Tipi e protocolli

I nomi di tipo e protocollo dovrebbero iniziare con una lettera maiuscola.

Esempio:

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

Tutto il resto ...

Variabili, costanti, funzioni e casi di enumerazione dovrebbero iniziare con una lettera minuscola.

Esempio:

let greeting = "Hello"
let height = 42.0

enum Color {
    case red
    case green
    case blue
}

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

Cammello:

Tutti i nomi dovrebbero usare il caso cammello appropriato. Custodia di cammello superiore per nomi di tipo / protocollo e custodia di cammello inferiore per tutto il resto.

Cammello superiore:

protocol IteratorType { ... }

Cassa inferiore del cammello:

let inputView = ...

Abbreviazioni

Le abbreviazioni dovrebbero essere evitate a meno che non siano usate comunemente (es. URL, ID). Se viene utilizzata un'abbreviazione, tutte le lettere devono avere lo stesso caso.

Esempio:

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


Modified text is an extract of the original Stack Overflow Documentation
Autorizzato sotto CC BY-SA 3.0
Non affiliato con Stack Overflow