Incep acum o lista de standarde de codare pentru Swift 3 pe care o s-o actualizez in timp.

1. Swift Collection Types

incerc cat se poate sa evit folosirea tipurilor din Objective C – NSArray, NSDictionary, and NSSet. Exemplul cel mai des intalnit este prelucraerea unui JSON:
Calea pe care o folosesc de cele mai multe ori este:
var arrayOfJSONObjects = [[String: AnyObject]]()
...
let names: AnyObject? = (arrayOfJSONObjects as NSArray).value(forKeyPath: "name")

O pot adapta intr-un mod cat mai Swifty prin utilizarea flatMap astfel:

var arrayOfJSONObjects = [[String: AnyObject]]()
...
let names: [String] = arrayOfJSONObjects.flatMap { object in
return object["name"] as? String
}

2. Optionals

Discutia despre optionals este lunga si la inceput m-am uitat cu mirare la acest nou tip de date. De ce ar mai fi nevoie de inca un tip de date in plus care sa contina doua valori, nil daca in “borcanel” nu e nimic sau valoarea propriu-zisa, daca “borcanelul” e plin?
Numai utilizand si codand, mi-am dat seama de puterea optioanls.
Discutiile pe tema lor ar include urmatoarele aspecte:

2.1. Force unwrapping

In general evit sa fortez unwrapping-ul optional-ului. Utilizarea lui as! sau ! poate genera un crash in prezenta unui nil. Swift recomanda utilizarea uneia dintre variantele: guard let, if let, guard let as?, if let as? sau optional chaining.

Un astfel de caz:

// URL init(string:) este un failable initializer, adica putem avea genera un nil datorat lipsei string-ului

let url = URL(string: “http://www.example.com/”)!
UIApplication.shared.open(url)

O solutie Swifty in acest caz ar fi:

// prezenta guard-ului imi garanteaza faptul ca open(url) se va executa doar in cazul in care url nu este nil

guard let url = URL(string: "http://www.example.com/") else {
return
}
UIApplication.shared.open(url)

O alta situatie cu care m-am confruntat este folosirea incorecta a unui optional chaining.
O astfel de abordare ca cea de mai jos poate forta existenta metodei delegatului, in conditiile in care delegatului poate da in nil.:
self.delegate!.didSelectItem(item)
Corect ar fi sa scriu:
self.delegate?.didSelectItem(item)

2.2. Pyramid of Doom – if let

Deseori m-am confruntat cu acest caz de Pyramid of Doom:
if let id = jsonObject[Constants.id] as? Int {
if let firstName = jsonObject[Constants.firstName] as? String {
if let lastName = jsonObject[Constants.lastName] as? String {
if let initials = jsonObject[Constants.initials] as? String {
let user = User(id: id, firstName: name, lastName: lastName, initials: initials)
// ...
}
}
}
}

Pentru a evita imbricarea if let-urilor, corect ar fi:

if

let id = jsonObject[Constants.Id] as? Int,
let firstName = jsonObject[Constants.firstName] as? String,
let lastName = jsonObject[Constants.lastName] as? String,
let initials = jsonObject[Constants.initials] as? String {
let user = User(id: id, name: name, initials: initials)
// …
}

2.3 guard let vs. if let

Chiar daca la inceput foloseam din reflex if let, am realizat in timp puterea lui guard let. Codul arata mai bine, e mult mai clar cu guard let
Astfel in loc de

func openURL(string: String) {
if let url = URL(string: string) {
UIApplication.shared.open(url)
}
}

prefer sa folosesc pentru claritate:

func openURL(string: String) {
guard let url = URL(string: string) else {
return
}
UIApplication.shared.open(url)
}

3. Tratarea erorilor

Este de evitat folosirea unei secvente try! sub aceasta forma:
let json = try! JSONSerialization.jsonObject(with: data, options: .allowFragments)
print(json)
Pot aparea erori pe parsarea de date astfel incat try! sa duca in crash.
Este recomandata o sintaxa sub forma urmatoare:
do {
let json = try JSONSerialization.jsonObject(with: data, options: .allowFragments)
print(json)
} catch {
print(error)
}