Swift-style-guide: Inconsistência na inicialização de matrizes e dicionários vazios

Criado em 7 abr. 2017  ·  4Comentários  ·  Fonte: raywenderlich/swift-style-guide

Eu teria que dizer que concordo com a maior parte do que está declarado nas diretrizes, mas este parece inconsistente:

https://github.com/raywenderlich/swift-style-guide#type -annotation-for-empty-arrays-and-dicionários

O guia indica:

// preferred
var names: [String] = []
var lookup: [String: Int] = [:]

é preferido sobre

// not preferred
var names = [String]()
var lookup = [String: Int]()

Mas o guia geralmente prefere tipos inferidos no interesse do código compacto:

// preferred
let message = "Click the button"
let currentBounds = computeViewBounds()

`` `rápido
// não preferido
let message: String = "Clique no botão"
deixe currentBounds: CGRect = computeViewBounds ()

If we were being consistent, shouldn't we always prefer inferred types over explicit declaration?  I would think this is more consistent
```swift
// should be preferred
var names = [String]();
var lookup = [String: Int]();

Comentários muito úteis

Na minha opinião, o guia está correto aqui. Ele simplesmente diz, quando necessário, especifique o tipo. Quando não, largue isso.

Ok, mas isso não é realmente uma escolha de estilo? Não, na verdade não. Vamos dar uma olhada em alguns exemplos:

// preferred
var colors: [UIColor]?
var colors: [UIColor] = []
var colors: [UIColor] = [.red, .green, .blue]

Agora, vamos converter esses 3 exemplos em sua preferência sugerida.

var colors: [UIColor]?
var colors = [UIColor]()
var colors = [UIColor.red, UIColor.green, UIColor.blue]

Veja o que aconteceu ai? Para a última linha, agora precisamos repetir UIColor para cada elemento do array. Você também pode argumentar que as declarações agora são menos consistentes umas com as outras.

Que tal um método então? Bem, é claro que você pode escolher sempre especificar o tipo para ser consistente. No entanto, eu imagino que a maioria dos desenvolvedores gostaria de acabar com o código redundante.

// do we need to specify type?
var colors: [UIColor] = rainbowColors()
// no we don't
var colors = rainbowColors()

Isso faz sentido?

_Editar: com toda a justiça, você também poderia inferir um array como este, mas, dado que estamos falando de consistência, estou considerando este fora da mesa. Achei que estaria certo._

// preferred
var colors: [UIColor] = [.red, .green, .blue]
// not preferred
var colors = [.red, UIColor.green, .blue]

Todos 4 comentários

Na minha opinião, o guia está correto aqui. Ele simplesmente diz, quando necessário, especifique o tipo. Quando não, largue isso.

Ok, mas isso não é realmente uma escolha de estilo? Não, na verdade não. Vamos dar uma olhada em alguns exemplos:

// preferred
var colors: [UIColor]?
var colors: [UIColor] = []
var colors: [UIColor] = [.red, .green, .blue]

Agora, vamos converter esses 3 exemplos em sua preferência sugerida.

var colors: [UIColor]?
var colors = [UIColor]()
var colors = [UIColor.red, UIColor.green, UIColor.blue]

Veja o que aconteceu ai? Para a última linha, agora precisamos repetir UIColor para cada elemento do array. Você também pode argumentar que as declarações agora são menos consistentes umas com as outras.

Que tal um método então? Bem, é claro que você pode escolher sempre especificar o tipo para ser consistente. No entanto, eu imagino que a maioria dos desenvolvedores gostaria de acabar com o código redundante.

// do we need to specify type?
var colors: [UIColor] = rainbowColors()
// no we don't
var colors = rainbowColors()

Isso faz sentido?

_Editar: com toda a justiça, você também poderia inferir um array como este, mas, dado que estamos falando de consistência, estou considerando este fora da mesa. Achei que estaria certo._

// preferred
var colors: [UIColor] = [.red, .green, .blue]
// not preferred
var colors = [.red, UIColor.green, .blue]

Eu teria ido com

var colors: [UIColor]?
var colors = [UIColor]()
var colors: [UIColor] = [.red, .green, .blue]

Em vez do que você fez acima. Não estamos preferindo usar o tipo inferido, exceto quando uma declaração explícita é necessária? Nesse sentido, a terceira linha parece consistente.

Você está certo no sentido de que provavelmente simplifiquei demais a regra. Dito isso, não há nada de errado com as duas abordagens, tudo se resume à preferência. No meu caso, acho o seguinte mais consistente, mais legível e mais prático ao ir e voltar estados vazio / não vazio. Acho que devemos deixar os outros intervirem.

// preferred
var colors: [UIColor]?
var colors: [UIColor] = []
var colors: [UIColor] = [.red]
// not preferred (in my opinion)
var colors: [UIColor]?
var colors = [UIColor]()
var colors: [UIColor] = [.red]

O problema que você tem com isso é esta inconsistência:

// inconsistent?
var colors: [UIColor] = []
var colors = rainbowColors()
// your preference
var colors = [UIColor]()
var colors = rainbowColors()

@RobertGummesson , você está levando em consideração apenas os tipos mais usados ​​com a sintaxe literal de array / dicionário. Se apenas tivéssemos arrays para preencher com literais de array, ambas as soluções estariam bem. Eu até costumava usar o que você estava sugerindo. Mas então nós temos os conjuntos e eu tive que padronizar uma convenção que os incluísse também. O que você está sugerindo é mais feio do que a digitação explícita.

var ints: Set = [1, 1, 2, 2]
var ints = Set([1, 1, 2, 2])
var ints = Set(arrayLiteral: 1, 1, 2, 2)

Portanto, após decidir que a primeira escolha é a melhor para conjuntos não vazios, uma versão vazia e convenções de array correspondentes podem ser convertidas.

var ints: Set<Int> = []
var ints = Set<Int>() // instead of this, which, without the above, seems fine.

var ints = [1, 1, 2, 2]
var ints: [Int] = []
Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

sima-11 picture sima-11  ·  5Comentários

luki picture luki  ·  3Comentários

jrturton picture jrturton  ·  3Comentários

rwenderlich picture rwenderlich  ·  29Comentários

ghost picture ghost  ·  26Comentários