Swift-style-guide: Estilo de declaração de guarda

Eu gosto desta sugestão.... modulo 2-space 4-space indentation :]

Começando a ter dúvidas sobre este. Eu vi muito código rápido, de autores de bibliotecas que eu realmente admiro fazendo guardas como um forro. Algum pensamento @JRG-Developer @eskerber @jawwad @gregheo ?

Possível compromisso: mostrar todos os exemplos usando o formato acima, mas não legislar sobre ele.

Aqui estão meus pensamentos:

• Em primeiro lugar, faça com que o texto tenha uma boa aparência em impressão/web/qualquer formato pretendido. Muitas vezes, isso significa adicionar retornos onde você normalmente _não_ incluiu retornos no Xcode.

• Para guardas de declaração única, eu prefiro isso:

guard let strongSelf = self else { return nil }

Meu raciocínio é que _não_ normalmente é crítico para qualquer que seja o objetivo principal do método. Claro, é definitivamente obrigatório estar lá, mas não acho que valha a pena desperdiçar três linhas em guardas simples como este.

Isso também ajuda a tornar o texto impresso, web, etc um pouco mais curto, o que é uma vantagem.

• Para guardas de várias instruções, eu prefiro isso:

guard let name = json["name"] as? String,
  let coordinatesJSON = json["coordinates"] as? [String: Double],
  let latitude = coordinatesJSON["lat"],
  let longitude = coordinatesJSON["lng"],
  let mealsJSON = json["meals"] as? [String] else { return nil }

A diferença aqui é manter o else na mesma linha do último desempacotamento.
O raciocínio é o mesmo: esse não é o caminho esperado, e não vale a pena desperdiçar o espaço.

Peguei emprestado o formato inicial da Apple, mas também mudei meu estilo de código. É razoável usar um one-liner se você estiver retornando instantaneamente.

Aqui está a nova versão:

Solteiro:

guard let name = json["name"] as? String else { return nil }

Vários:

guard let name = json["name"] as? String,
    let coordinatesJSON = json["coordinates"] as? [String: Double],
    let latitude = coordinatesJSON["lat"],
    let longitude = coordinatesJSON["lng"],
    let mealsJSON = json["meals"] as? [String]
else { return nil }

Acho que else merece sua própria linha quando há vários let s.

Tê-lo em uma linha impede que você coloque um ponto de interrupção no caso de falha, não?

@rayfix sim , você não pode fazer isso... ¯_(ツ)_/¯

Eu tentei e usei esses dois estilos e minha preferência acabou sendo a opção de uma linha também. Na minha opinião, ter um código mais conciso e legível supera qualquer desvantagem.

Eu posso ver de onde as pessoas que discordam estão vindo. Além do problema mencionado pelo @rayfix , vejo duas outras desvantagens.

Às vezes, eles acabam sendo relativamente longos, tornando-os menos legíveis. (Tenho certeza de que poderia encontrar exemplos mais extremos):

Várias linhas:

guard let meal = Meal(rawValue: string) else {
    throw SerializationError.invalid("meals", string)
}

Uma linha:

guard let meal = Meal(rawValue: string) else { throw SerializationError.invalid("meals", string) }

O outro problema é apenas consistência. Eu nunca faria uma condição if de uma linha, por exemplo.

Mas, novamente, minha preferência ainda é usar uma linha. Apenas tentando virar mais algumas pedras.

Minha inclinação é que não há nenhuma regra dura e rápida sobre isso. Talvez devêssemos ser explícitos sobre isso do jeito que fomos com o encadeamento de fechamento.

As decisões sobre espaçamento, quebras de linha e quando usar argumentos nomeados versus anônimos são deixadas a critério do autor.

Fiz uma pesquisa informal de algumas bibliotecas Swift altamente estreladas, incluindo a Swift Standard Library, Almofire, Unbox, SwiftyJSON, Spring. Não há um consenso real que eu possa encontrar. Todos eles parecem muito bons para mim em seu próprio contexto.

Mesmo no exemplo do Apple JSON de https://developer.apple.com/swift/blog/?id=37 eles colocam o else em lugares diferentes na mesma função! Isso não quer dizer que parece ruim. Na verdade, parece bom aos meus olhos.

Então, acho que estou caindo no campo de querer abraçar a flexibilidade que a linguagem permite. Acho que isso favorece a legibilidade (clareza) em detrimento de alguma consistência.

Posso estar errado, mas não quero segurar o release sobre esse assunto. Meu objetivo é que o documento seja revisado pela equipe na segunda-feira para que possa ser mesclado na quinta-feira. Se você quiser apelar, eu sou totalmente legal com isso! Por favor, indique seu caso (aqui) e eu o encaminharei aos líderes da equipe para tomar uma decisão final.

Independentemente disso, quero agradecer a você por trazer essa questão, pois ela me deu mais clareza e desencadeou algumas discussões e insights úteis.