Рассмотрим этот фрагмент кода:
if (x == 1)
{
throw "no good; aborting" ;
}
[... more code ...]
Теперь рассмотрим этот код:
if (x == 1)
{
throw "no good; aborting" ;
}
else
{
[... more code ...]
}
Два случая работают точно так же. Преимущество первого случая состоит в том, что вам не нужно «заключать» остальную часть кода в else
. Второе преимущество заключается в следовании практике явного наличия else
каждого if
.
Может ли кто-нибудь привести веские аргументы в пользу одного над другим?
coding-style
exceptions
rlandster
источник
источник
else
кажется фальшивой. Довольно часто просто нечего положить вelse
блок, если вы не наклонитесь назад.if
нужна каждомуelse
. Последний программист, который работал над нашей кодовой базой, строго следовал этому ( ну, иногда ... это отчасти шизофренично ). В результате у нас есть много совершенно бессмысленныхelse { /* do nothing */ }
блоков, засоряющих код ...Ответы:
Не следует добавлять
else
послеif
веток, которые безоговорочно нарушают поток управления , таких как ветки , содержащие athrow
или areturn
. Это улучшит читабельность вашей программы, удалив ненужный уровень вложенности, введенныйelse
веткой.То, что выглядит более-менее нормально с одним,
throw
становится по-настоящему уродливым, когда включается несколько бросков подряд:Этот фрагмент делает то же самое, но выглядит намного лучше:
источник
else if
.if
тестирует одно условие и имеет дело с ним, если условие истинно, и если не существует какой-то альтернативы, которая должна произойти, если условие ложно,else if
s не нужны. У нас есть термин вокруг моего офиса для кода , как первый фрагмент dasblinkenlight в: « пачинко машины.»else
.Я бы назвал практику «явного другого», которую вы называете анти-паттерном, так как она скрывает тот факт, что нет специального кода в качестве еще одного для вашего if.
Удобочитаемость / удобство сопровождения обычно улучшаются, когда у вас нет ничего, кроме необходимых конструкций потока кода, и вы минимизируете их. Это означает избыточные Elses и if, которые добавят область действия ко всей функции, затрудняют отслеживание и поддержку.
Скажем, например, у вас есть эта функция:
Теперь возникает требование, что во время конфигурации вы также должны указать индекс типа / типа облогона, есть несколько областей, в которые кто-то может поместить этот код и получить неверный код, т.е.
Сравните это с тем, если исходный код был написан с минимальными необходимыми конструкциями потока управления и при этом свернутыми.
Теперь было бы гораздо сложнее случайно поместить что-то в неправильную область или в конечном итоге вздутие области действия, что приведет к дублированию в долгосрочной перспективе роста и поддержания этой функции. Кроме того, очевидно, что возможные потоки через эту функцию повышают читабельность.
Я знаю, пример немного надуманный, но я много раз видел
Поэтому формализация этих правил для конструкций потока управления, я думаю, может помочь людям развить интуицию, необходимую для того, чтобы что-то почувствовать, когда они начнут писать такой код. Тогда они начнут писать ..
источник