Swift-style-guide: Стиль заявления гвардии

Мне нравится это предложение.... отступ по модулю 2-space 4-space :]

Начинаю сомневаться в этом. Я видел много быстрого кода от авторов библиотек, которыми я действительно восхищаюсь, выполняя охрану как один лайнер. Любые мысли @JRG-Developer @eskerber @jawwad @gregheo ?

Возможный компромисс: показать все примеры, используя вышеуказанный формат, но не узаконивать его.

Вот мои мысли:

• Прежде всего, сделайте так, чтобы текст хорошо выглядел в печатном/веб-формате/в любом другом формате. Часто это означает добавление возвратов туда, где вы обычно _не_ включали возвраты в Xcode.

• Для охранников с одним оператором я предпочитаю это:

guard let strongSelf = self else { return nil }

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

Это также помогает сделать текст в печати, Интернете и т. д. немного короче, что является плюсом.

• Для охранников с несколькими операторами я предпочитаю это:

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 }

Разница здесь в том, что else остается на той же строке, что и последняя распаковка.
Причина та же: это не ожидаемый путь, и не стоит тратить место впустую.

Я позаимствовал первоначальный формат у Apple, но затем также изменил стиль кода. Разумно использовать однострочник, если вы возвращаетесь мгновенно.

Вот новая версия:

Одинокий:

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

Мульти:

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 }

Я думаю, что else заслуживает отдельной строки, когда есть несколько let s.

Наличие его в одной строке не позволяет вам поставить точку останова в случае сбоя, нет?

@rayfix да , вы не можете этого сделать... ¯_(ツ)_/¯

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

Хотя я вижу, откуда берутся несогласные. Помимо проблемы, упомянутой @rayfix , я вижу еще два недостатка.

Иногда они становятся относительно длинными, что делает их менее читабельными. (Я уверен, что мог бы найти более экстремальные примеры):

Несколько строк:

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

Одна линия:

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

Другая проблема заключается только в согласованности. Например, я бы никогда не выполнил однострочное условие if .

Но опять же, я предпочитаю использовать одну строку. Просто пытаюсь перевернуть еще несколько камней.

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

Решения об интервалах, разрывах строк и использовании именованных или анонимных аргументов остаются на усмотрение автора.

Я провел неофициальный обзор некоторых высоко оцененных библиотек Swift, включая стандартную библиотеку Swift, Almofire, Unbox, SwiftyJSON, Spring. Нет реального консенсуса, который я могу найти. Все они кажутся мне довольно хорошими в своем собственном контексте.

Даже в примере Apple JSON с https://developer.apple.com/swift/blog/?id=37 они помещают else в разные места в одной и той же функции! Это не значит, что это выглядит плохо. Это на самом деле выглядит хорошо для моего глаза.

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

Я могу ошибаться, но я не хочу задерживать релиз по этому вопросу. Моя цель состоит в том, чтобы команда рассмотрела документ в понедельник, чтобы его можно было объединить в четверг. Если вы хотите подать апелляцию, я полностью согласен с этим! Пожалуйста, изложите свое дело (здесь), и я передам его руководителям группы для принятия окончательного решения.

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