«еще» считается вредным в Python? - PullRequest
11 голосов
/ 15 мая 2009

В ответе ( S.Lott) на вопрос о try...else утверждении Python:

На самом деле, даже в операторе if иначе: может быть оскорблен по-настоящему ужасно способы создания ошибок, которые очень трудно найти. [...]

Подумайте дважды о другом: это вообще проблема. Избегайте этого, кроме в операторе if и даже тогда рассмотреть возможность документирования остального условие, чтобы сделать это явным.

Это широко распространенное мнение? else считается вредным ?

Конечно, вы можете написать с ним запутанный код, но это верно для любой другой языковой конструкции. Даже Python for...else кажется мне очень удобным (меньше для try...else).

Ответы [ 13 ]

30 голосов
/ 15 мая 2009

С.Лотт явно видел какой-то плохой код. Разве мы не все? Я не считаю, что это вредно, хотя я видел, как он писал плохой код. В этих случаях весь окружающий код тоже был плохим, так зачем винить бедного еще?

15 голосов
/ 15 мая 2009

Нет, это не вредно, это необходимо.

Всегда должно быть всеобъемлющее заявление. Все переключатели должны иметь значение по умолчанию. Все сопоставления с образцом на языке ML должны иметь значение по умолчанию.

Аргумент, что невозможно рассуждать о том, что является правдой после серии утверждений if, факт жизни. Компьютер - это самый большой конечный автомат, и глупо перечислять каждую возможность в каждой ситуации.

Если вы действительно боитесь, что неизвестные ошибки останутся незамеченными в инструкциях else, неужели так сложно вызвать исключение?

7 голосов
/ 15 мая 2009

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

The only valid inputs are 1 and 2:

if(input == 1)
{
   //do processing
   ...
}
else
{
   //do processing 
   ...
}

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

7 голосов
/ 15 мая 2009

Сказать, что еще считается вредным, - все равно, что сказать, что переменные или классы вредны. Черт возьми, это все равно что говорить, что goto вредно. Конечно, вещи могут быть использованы не по назначению. Но в какой-то момент вы просто должны доверять программистам, чтобы быть взрослыми и быть достаточно умными, чтобы не делать этого.

То, к чему это сводится, заключается в следующем: если вы готовы не использовать что-либо, потому что ответ на SO, сообщение в блоге или даже на известную статью Dijkstra говорит вам не делать этого, вам следует подумать, является ли программирование правильным профессия для тебя.

6 голосов
/ 15 мая 2009

Для меня вся концепция некоторых популярных языковых конструкций по своей сути плоха, просто ошибочно. Даже goto имеет свое место. Я видел очень читабельный, поддерживаемый код, подобный Уолтеру Брайту и Линусу Торвальдсу, который его использует. Гораздо лучше просто научить программистов считать читаемость и использовать здравый смысл, чем произвольно объявлять некоторые конструкции «вредными».

4 голосов
/ 15 мая 2009

Если вы напишите:

if foo:
    # ...
elif bar:
    # ...
# ...

тогда читатель может задаться вопросом: а что если ни foo, ни bar не соответствует действительности? Возможно, вы знаете, исходя из своего понимания кода, что это должен быть случай либо foo, либо bar. Я бы предпочел увидеть:

if foo:
    # ...
else:
    # at this point, we know that bar is true.
    # ...
# ...

или

if foo:
    # ...
else:
    assert bar
    # ...
# ...

Это дает читателю понять, как вы ожидаете, что контроль будет проходить, не требуя от читателя глубоких знаний о том, откуда foo и bar.

(в исходном случае вы все еще могли бы написать комментарий, объясняющий, что происходит, но я думаю, что тогда я задаюсь вопросом: «Почему бы просто не использовать предложение else:?»)

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

Что верно для большинства вещей в языках программирования, правда: -)

3 голосов
/ 15 мая 2009

Au contraire ... На мой взгляд, ДОЛЖНО быть другое для каждого if. Конечно, вы можете делать глупости, но вы можете злоупотреблять любой конструкцией, если будете стараться изо всех сил. Вы знаете высказывание «настоящий программист может писать на фортране на любом языке».

Что я делаю много времени, так это пишу остальную часть как комментарий, описывающий, почему ничего не поделаешь.

3 голосов
/ 15 мая 2009

Остальное наиболее полезно при документировании предположений о коде. Это гарантирует, что вы продумали обе стороны оператора if.

Всегда используйте условие else с каждым условным оператором if, даже рекомендуемой практикой в ​​«Code Complete».

2 голосов
/ 15 мая 2009

Основанием для включения в Python оператора else (из try...else) в первую очередь было отловить только те исключения, которые вы действительно хотите. Обычно, когда у вас есть блок try...except, есть некоторый код, который может вызвать исключение, а затем есть еще некоторый код, который должен запускаться только в том случае, если предыдущий код был успешным. Без блока else вы должны поместить весь этот код в блок try:

try:
    something_that_might_raise_error()
    do_this_only_if_that_was_ok()
except ValueError:
    # whatever

Вопрос в том, что, если do_this_only_if_that_was_ok() поднимает ValueError? Это было бы поймано оператором except, когда вы, возможно, этого не хотели. Это цель блока else:

try:
    something_that_might_raise_error()
except ValueError:
    # whatever
else:
    do_this_only_if_that_was_ok()

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

1 голос
/ 16 мая 2009

Существует так называемая проблема "висячего другого", которая встречается в языках семейства C следующим образом:

if (a==4)
if (b==2)
printf("here!");
else
printf("which one");

Этот невинный код можно понять двумя способами:

if (a==4)
    if (b==2)
        printf("here!");
    else
        printf("which one");

или

if (a==4)
    if (b==2)
        printf("here!");
else
    printf("which one");

Проблема в том, что "else" "висят", можно запутать владельца else. Конечно, компилятор не будет создавать путаницу, но он действителен для смертных.

Благодаря Python у нас не может быть висячей проблемы в Python, так как мы должны написать либо

if a==4:
    if b==2:
        print "here!"
else:
    print "which one"

или

if a==4:
    if b==2:
        print "here!"
    else:
        print "which one"

Так что человеческий глаз это ловит. И нет, я не думаю, что «еще» вредно, это так же вредно, как «если».

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...