Swift-style-guide: 空の配列と辞書の初期化における不整合

作成日 2017年04月07日  ·  4コメント  ·  ソース: raywenderlich/swift-style-guide

ガイドラインに記載されている内容のほとんどに同意しますが、これは一貫性がないようです。

https://github.com/raywenderlich/swift-style-guide#type -annotation-for-empty-arrays-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()

`` `スイフト
//好ましくない
メッセージを聞かせてください: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()

それは理にかなっていますか?

_編集:公平を期すために、このような配列を推測することもできますが、一貫性について話しているので、これをテーブルから外すことを検討しています。 私が正しいと思っただけです。_

// 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()

それは理にかなっていますか?

_編集:公平を期すために、このような配列を推測することもできますが、一貫性について話しているので、これをテーブルから外すことを検討しています。 私が正しいと思っただけです。_

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

あなたが上でしたことの代わりに。 明示的な宣言が必要な場合を除いて、推論された型を使用することを好みませんか? その意味で、3行目は一貫しているようです。

私がおそらくルールを単純化しすぎたという意味であなたは正しいです。 そうは言っても、どちらのアプローチにも問題はありません。それは好み次第です。 私の場合、空の状態と空でない状態を行ったり来たりするときに、以下の方が一貫性があり、読みやすく、実用的であることがわかります。 他の人にチャイムを鳴らしてもらうべきだと思います。

// 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 評価