Введение
В программировании программисты обычно используют множество техник, чтобы получить желаемый результат от ряда аргументов. Чтобы использовать эти методы в языках программирования высокого уровня, мы часто используем ключевые слова. Программисты чаще всего используют для этой цели условные выражения и циклы, и как можно более эффективное их использование - вот что составляет программирование.
При этом всегда есть неправильный и правильный способ подойти к проблеме и использовать эти методы для ее решения. Одной из спорных тем для разговоров в этом отношении является ключевое слово else. Многие программисты полностью исключили ключевое слово else из своей группы программистов. Это потому, что есть несколько проблем, которые возникают вместе с использованием else, хотя, безусловно, есть случаи, когда else полезно для решения проблемы. Но что же делает заявления else такими плохими? Есть ли что-то еще, что можно было бы полностью избежать использования else, или это просто еще одно из тех утверждений, которые программисты делают, чтобы запугать других? Сегодня я хотел проанализировать свой субъективный опыт неправильного использования ключевого слова else и обсудить, что я думаю об этой методологии, не связанной с else. Надеюсь, предоставленная информация может пролить свет на некоторые потенциальные проблемы с вашим собственным кодом или повлиять на то, как вы структурируете условные выражения каким-либо образом.
"Ноутбук"
Гнездование
Чтобы понять проблемы с блоками else, нам нужно сначала понять вложение. Во многих отношениях мы можем думать о вложении как о слоях в определенный блок кода. При вложении важно помнить, что это сам по себе цикл, независимо от того, повторяется он или нет. Все, что вложено, вероятно, будет иметь свою собственную область видимости, а это означает, что значения, объявленные в ее области, не будут глобальными.
Более того, простой метод - это уровень вложения непосредственно под глобальной областью видимости. В примере с модулем у нас может быть уровень вложенности, переходящий от глобального к модулю, затем метод внутри модуля, а затем итерационный цикл внутри этого метода. Давайте взглянем на итерационный цикл, чтобы продемонстрировать это дальше.
for iteration in range(1, 5):
z = 5
print(z)
Внутри этого цикла мы определили новую переменную z, которая содержит целое число 5. Всякий раз, когда мы пытаемся использовать это значение в рамках этого цикла for, мы видим, что значение печатается четыре раза, по одному разу для каждой итерации. в диапазоне 1: 5. Мы можем добавить к этой функции еще один уровень вложенности, написав так называемый вложенный цикл for. По сути, это цикл внутри цикла. Теперь, когда мы запускаем цикл внутри цикла, все очень быстро усложняется, так как для того, чтобы теперь работать с z, нам нужно рассмотреть все циклы, с которыми работали до этого.
for iteration in range(1, 5):
z = 5
for i in range(1, z):
print("iteration")
print(z)
Это может быть очень проблематично для удобочитаемости, потому что это означает, что любой, кто читает наш код, должен будет обратиться к нашему предыдущему коду, чтобы понять, с какими переменными мы работаем. Точно так же серия циклов for, работающих вместе одновременно, может сбивать с толку. Мы также можем делать то же самое с условными предложениями и создавать вложенные условные выражения. Легко понять, почему чрезмерное использование вложенности может очень быстро сделать ваш проект запутанным и запутанным для любого, кто пытается прочитать ваш код. Но какое отношение все это имеет к другому?
Еще
Теперь, когда мы понимаем вложенность, существенная проблема else, когда дело касается читабельности, быстро становится очевидной. Ключевое слово else в значительной степени зависит от кода, который написан перед ним. Мы не можем использовать блок else, предварительно не написав блок if. Следующий код, например, недопустимый синтаксис:
else:
print("hi")
Это означает, что каждый раз, когда мы добавляем оператор else, мы также добавляем за ним все виды вложенности, даже не осознавая этого. Рассмотрим следующую функцию:
def else_test(x):
if x == 5:
print("five")
elif x == 4:
print("four")
elif x == 3:
print("three")
elif x == 2:
print("two")
else:
print("one")
Чтобы этот код когда-либо напечатал единицу, x не сможет равняться пяти, четырем, трем или двум. Каждое из этих условий - это то, что программист должен учитывать при анализе кода. Кроме того, elifs в этом коде выполняют те же функции. В результате каждый последующий условный оператор в этом коде имеет еще один уровень вложенности.
Условия реструктуризации
Учитывая функцию, которую я написал выше, давайте теперь реорганизуем ее, используя только if, а затем я коснусь того, действительно ли вам нужно это делать. Чтобы изменить этот код, нам в значительной степени просто нужно изменить все наши elif на if, а наш else на новый оператор if.
def else_test(x):
if x == 5:
print("five")
if x == 4:
print("four")
if x == 3:
print("three")
if x == 2:
print("two")
if x == 1:
print("one")
Конечно, у этого нового кода есть несколько преимуществ и недостатков. Во-первых, из этой функции вообще не будет возврата, если мы введем число шесть. Во-вторых, код намного легче читать, потому что мы можем читать каждый вложенный блок индивидуально. В этом примере может показаться, что это не так, но в большинстве реальных ситуаций программирования это будет намного легче читать. Это потому, что нам не придется возвращаться к тому, что происходит в первых четырех, когда мы дойдем до пятого.
Теперь, если бы я написал эту функцию, какой код я бы написал? Конечно, ответ - это первый пример. Я думаю, что есть место и время для написания условных выражений в обоих направлениях, и избегать путаницы - трудный путь, по которому нужно ориентироваться со всей честностью. Невозможно впервые проанализировать свой код после того, как вы его написали. Читаемость сводится к тому, что вы пытаетесь читать собственный код, например, английский. Вы должны иметь возможность смотреть на свой код построчно и говорить, что делает каждая строка. Есть так много вещей, которые способствуют нечитабельности кода, и хотя я думаю, что некоторые операторы else определенно плохи, я не считаю грехом использовать само ключевое слово.
Вывод
Вложенность - важный компонент компьютерного программирования. Это позволяет нам сделать гораздо более простой код намного более мощным. Однако большие возможности влекут за собой большую ответственность, и вложенность может полностью разрушить читабельность вашего кода, если вы не будете осторожны. По моему субъективному мнению, использование ключевого слова else вполне приемлемо. Однако, как и все в жизни, включая воду и пищу, его следует употреблять в умеренных количествах.
Чрезмерное использование условных выражений - это то, что я назвал плохой практикой программирования в моей статье о рефакторинге кода. Если у вас не было возможности прочитать эту статью, она доступна здесь, и я думаю, что ее, безусловно, стоит прочитать:
Чрезмерное использование условных выражений также относится к чрезмерному использованию else. Когда его используют, это должно быть осознанное решение. Вы также должны учитывать накладные расходы на каждое указанное выше условие и обратите внимание, что else выполняется только тогда, когда все эти условия пропущены. Другими словами, любому программисту, работающему с вашим программным обеспечением, нужно будет выяснить, как вызывается это еще, и если оно вложено ниже сотен условных выражений, это может быть довольно сложно. Я не думаю, что нужно полностью вырезать его из вашей программной полки, но я считаю, что к нему нужно относиться ответственно! Спасибо, что прочитали мою статью, и я надеюсь, что она заставила вас задуматься о другом и вложенности!
