Swift-style-guide: Incohérence dans l'initialisation des tableaux et dictionnaires vides

À mon avis, le guide est correct ici. Il dit simplement, si nécessaire, spécifiez le type. Sinon, lâchez-le.

D'accord, mais n'est-ce pas vraiment un choix de style ? Non, pas vraiment. Voyons quelques exemples :

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

Maintenant, convertissons ces 3 exemples en votre préférence suggérée.

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

Vous voyez ce qui s'est passé là-bas ? Pour la dernière ligne, nous devons maintenant répéter UIColor pour chaque élément du tableau. Vous pouvez également faire valoir que les déclarations sont désormais moins cohérentes les unes avec les autres.

Et une méthode alors ? Eh bien, vous pouvez bien sûr choisir de toujours spécifier le type par souci de cohérence. Cependant, j'imagine que la plupart des développeurs voudraient supprimer le code redondant.

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

Cela a-t-il du sens?

_Edit : En toute honnêteté, vous pouvez également déduire un tableau comme celui-ci, mais étant donné que nous parlons de cohérence, je considère celui-ci hors de la table. Je pensais juste que j'aurais raison._

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

je serais parti avec

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

Au lieu de ce que vous avez fait ci-dessus. Ne préférons-nous pas utiliser le type inféré sauf lorsqu'une déclaration explicite est requise ? En ce sens, la troisième ligne semble cohérente.

Vous avez raison dans le sens où j'ai probablement trop simplifié la règle. Cela dit, il n'y a rien de mal avec l'une ou l'autre des approches, cela dépend simplement de la préférence. Dans mon cas, je trouve la suite plus cohérente, plus lisible et plus pratique lors des allers et retours d'états vides/non vides. Je pense que nous devrions laisser les autres intervenir.

// 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]

Le problème que vous avez avec cela est cette incohérence:

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

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

@RobertGummesson , vous ne prenez en compte que les types les plus utilisés avec la syntaxe littérale de tableau/dictionnaire. Si nous n'avions que des tableaux à remplir avec des littéraux de tableau, les deux solutions conviendraient. J'utilisais même ce que vous suggériez. Mais ensuite nous avons eu des sets, et j'ai dû standardiser sur une convention qui les incluait aussi. Celui que vous suggérez est plus laid que la saisie explicite.

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

Ainsi, après avoir choisi le meilleur choix pour les ensembles non vides, une version vide et les conventions de tableau correspondantes peuvent être reformulées.

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] = []