Swift-style-guide: Несогласованность в инициализации пустых массивов и словарей

Созданный на 7 апр. 2017  ·  4Комментарии  ·  Источник: raywenderlich/swift-style-guide

Должен сказать, я согласен с большей частью того, что изложено в рекомендациях, но это кажется непоследовательным:

https://github.com/raywenderlich/swift-style-guide#type -annotation-for-empty-array-and-dictionaries

В руководстве указано:

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

предпочтительнее

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

Но руководство обычно предпочитает предполагаемые типы в интересах компактного кода:

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

`` быстрый
// не рекомендуется
let message: String = "Нажмите кнопку"
пусть 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]();

Самый полезный комментарий

На мой взгляд, руководство здесь правильное. Он просто говорит, что при необходимости укажите тип. Если нет, бросьте это.

Хорошо, но разве это не выбор стиля? Нет, не совсем. Давайте посмотрим на несколько примеров:

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

Теперь давайте преобразуем эти 3 примера в предложенные вами предпочтения.

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

Видите, что там произошло? Для последней строки нам теперь нужно повторить UIColor для каждого элемента в массиве. Вы также можете возразить, что декларации теперь менее согласованы друг с другом.

А как насчет метода? Что ж, вы, конечно, можете выбрать всегда указывать тип для обеспечения единообразия. Однако я полагаю, что большинство разработчиков захотят избавиться от избыточного кода.

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

Имеет ли это смысл?

_Edit: Честно говоря, вы также можете вывести такой массив, но, учитывая, что мы говорим о согласованности, я рассматриваю этот массив вне таблицы. Просто подумал, что буду прав ._

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

Все 4 Комментарий

На мой взгляд, руководство здесь правильное. Он просто говорит, что при необходимости укажите тип. Если нет, бросьте это.

Хорошо, но разве это не выбор стиля? Нет, не совсем. Давайте посмотрим на несколько примеров:

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

Теперь давайте преобразуем эти 3 примера в предложенные вами предпочтения.

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

Видите, что там произошло? Для последней строки нам теперь нужно повторить UIColor для каждого элемента в массиве. Вы также можете возразить, что декларации теперь менее согласованы друг с другом.

А как насчет метода? Что ж, вы, конечно, можете выбрать всегда указывать тип для обеспечения единообразия. Однако я полагаю, что большинство разработчиков захотят избавиться от избыточного кода.

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

Имеет ли это смысл?

_Edit: Честно говоря, вы также можете вывести такой массив, но, учитывая, что мы говорим о согласованности, я рассматриваю этот массив вне таблицы. Просто подумал, что буду прав ._

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

Я бы пошел с

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

Вместо того, что вы сделали выше. Разве мы не предпочитаем использовать предполагаемый тип, кроме случаев, когда требуется явное объявление? В этом смысле третья линия кажется последовательной.

Вы правы в том смысле, что я, наверное, слишком упростил правило. При этом нет ничего плохого в обоих подходах, все сводится к предпочтениям. В моем случае я считаю приведенное ниже более последовательным, более читаемым и более практичным при переходе туда и обратно пустых / непустых состояний. Я думаю, мы должны позволить другим вмешиваться.

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

Проблема в том, что это несоответствие:

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

@RobertGummesson , вы

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

Таким образом, после того, как мы остановимся на том, что лучший вариант лучше для непустых наборов, пустая версия и соответствующие соглашения о массивах могут быть сформированы обратно.

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] = []
Была ли эта страница полезной?
0 / 5 - 0 рейтинги