2014-12-07 3 views
-1

Итак, я читал книгу «Изучите Python трудный путь» Зед Шоу, и в ней говорится, что использование более чем 2-х слов глубоко. В настоящее время я пишу игру, и это имело бы больше смысла для меня, чтобы использовать несколько если заявления:Почему плохо считается, если говорить более двух, если заявление глубоко?

shoot = -50 
zombie_hp = -100 

def zombie1(shoot, zombie_hp): 
    return shoot - zombie_hp 

def attack(): 
    attack = raw_input("What will you do?: ") 
    print zombie1(zombie_hp, shoot) 
    if attack == "shoot": 
     if shoot == -50: 
      print "Zombie health 50/100" 
      attack2 = raw_input("What will you do?: ") 
      print zombie1(zombie_hp, shoot) 
      if attack == "shoot": 
       print "Zombie health 0/100 (Zombie dies)" 
attack() 

Теперь почему это плохо идти 3, если заявления глубоких по этому поводу? Благодаря!

+2

делать, если атака == стрелять и стрелять == -50: Это не буквально плохо (как все будет работать), но это зависит от контекста, на самом деле. Если вы не сможете использовать тонны операторов if, это сделает ваш код чистым. –

+1

Я думаю, что для всех языков: это просто уродливо смотреть. Кстати, вам не понадобится вторая «if attack ==» стрелять », как вы уже проверяли ее в своем первом выражении if. – Mikey

+0

Проблема здесь не в глубине гнездования как таковой, а в более плохом виде кода. Внутреннее 'if' является повторением частей внешнего, что оставило вас уязвимым для ошибки использования' attack' вместо 'attack2'. Кроме того, глобальные переменные - плохая идея; рассмотрите ООП, введите экземпляр класса «Зомби» с атрибутом «здоровье». – jonrsharpe

ответ

1

Мое преимущество заключается в том, что глубоко вложенный if ветвление может ограничивать, насколько легко ваш код может быть расширен. Учитывая ваш пример, что, если в будущем вы захотите применить атаки, которые наносят разный урон, или зомби с разным количеством hitpoints? Моя рекомендация заключалась бы в том, чтобы не поручать себе создание явно разных условий ветвления для каждой различной комбинации последовательностей атак и зомби.

Эта ссылка также дает некоторые более конкретные примеры того, почему вы можете захотеть, чтобы избежать этой схеме: http://c2.com/cgi/wiki?ArrowAntiPattern

0

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

2) Это делает ваш код негибким и хрупким.

3) Tell, don't ask

Смежные вопросы