Я нахожу, что у меня обычно нет проблем с чтением этих конечных условий (как их иногда называют), при условии, что все еще соблюдаются другие рекомендации по читаемости кода. Поместив 60-символьное выражение и 40-символьное условие в одну строку, вы получите 100-символьный текст, который, безусловно, будет нечитаемым, полностью независимым от вопроса конечных условий.
В показанном вами примере кода совершенно очевидно, что должно быть условным следующим. Кто захочет raise
ArgumentError
, даже не взглянув сначала на аргументы?
Кроме того, конечные условия аналогичны защитным предложениям в математических и функциональных языках, которые также имеют тенденцию быть написанными после выражения, которое они защищают.
И последнее, но не менее важное: размещение в начале методов пары выражений raise Bar if foo
и return nil if quux
в качестве охранников на самом деле считается хорошим стилем для упрощения потока управления метод. Опять же: поскольку они появляются в начале метода, становится очевидным, что имеет в качестве условия, в противном случае return
в начале метода не имеет смысла.
PS: Я бы на самом деле использовал unless
там, чтобы избавиться от отрицания. С более сложными условиями я нахожу, что unless
иногда бывает трудно проанализировать, но в этом случае, это больше очевидно, по крайней мере, ИМХО.