Иногда я разбиваю длинные условия в if
s на несколько строк. Наиболее очевидный способ сделать это:
if (cond1 == 'val1' and cond2 == 'val2' and
cond3 == 'val3' and cond4 == 'val4'):
do_something
Это не очень привлекательно визуально, потому что действие сочетается с условиями. Тем не менее, это естественный способ, используя правильный отступ Python для 4 пробелов.
На данный момент я использую:
if ( cond1 == 'val1' and cond2 == 'val2' and
cond3 == 'val3' and cond4 == 'val4'):
do_something
Но это не очень красиво. :-)
Можете ли вы порекомендовать альтернативный способ?
python
coding-style
if-statement
Эли Бендерский
источник
источник
pep8
критериям пакета. Вpep8
ПАКЕТЕ в выпуске № 126 о фиксации пакета строго следовать PEP8 спецификации. Обсуждение проблемы включает в себя некоторые предложения по стилю, которые также можно увидеть здесь.Ответы:
Вам не нужно использовать 4 пробела во второй условной строке. Может быть, использовать:
Кроме того, не забывайте, что пробелы более гибкие, чем вы думаете:
Оба из них довольно уродливы, хотя.
Может быть, потерять скобки ( Руководство стилю это не одобряет)?
Это, по крайней мере, дает вам некоторую дифференциацию.
Или даже:
Я думаю, что я предпочитаю:
Вот руководство по стилю , которое (с 2010 года) рекомендует использовать скобки.
источник
and
иif
.Я прибег к следующему в вырожденном случае, когда это просто И или ИЛИ.
Он бреет нескольких персонажей и дает понять, что в этом нет тонкости.
источник
if destroy_world and DestroyTheWorld() == world_is_destroyed: ...
. Отлично, теперь вы просто уничтожили мир случайно. КАК ТЫ МОГ?Кто-то должен защищать использование вертикальных пробелов здесь! :)
Это делает каждое условие ясно видимым. Это также позволяет более четко выражать более сложные условия:
Да, мы продаем немного вертикальной недвижимости для ясности. Стоит того ИМО.
источник
and
а такжеor
) находится после оператора, а не перед ним.PEP8
затрудняет определение логической операции, с которой вы соединяетесь. Я бы провалил это, если бы он пришел к моему столу через проверку кода.Я предпочитаю этот стиль, когда у меня ужасно большое условие if:
источник
and
иor
в начале строки нарушает PEP 0008 , который гласит: «Предпочтительное место для разбивки двоичного оператора - после оператора, а не перед ним». , Мне нравится иметь закрывающую скобку и двоеточие в отдельной строке, чтобы отделить условие if от тела, хотя (и это вполне возможно сделать, оставив ваши логические операторы в конце строки для соответствия PEP-0008).For decades the recommended style was to break after binary operators. But this can hurt readability in two ways
...In Python code, it is permissible to break before or after a binary operator, as long as the convention is consistent locally. For new code Knuth's style is suggested.
(стиль Кнута - начало строки с оператором).Вот мое очень личное мнение: длинные условия - это (на мой взгляд) запах кода, который предполагает рефакторинг в булево-возвращаемую функцию / метод. Например:
Теперь, если бы я нашел способ, чтобы многострочные условия выглядели хорошо, я, вероятно, был бы доволен их наличием и пропустил рефакторинг.
С другой стороны, их нарушение моего эстетического ощущения служит стимулом для рефакторинга.
Поэтому я пришел к выводу, что многопоточные условия должны выглядеть уродливыми, и это является стимулом избегать их.
источник
Это не так сильно улучшится, но ...
источник
Я предлагаю переместить
and
ключевое слово на вторую строку и сделать отступ для всех строк, содержащих условия, с двумя пробелами вместо четырех:Именно так я решаю эту проблему в своем коде. Наличие ключевого слова в качестве первого слова в строке делает условие намного более читабельным, а сокращение количества пробелов еще больше отличает условие от действия.
источник
Кажется, стоит цитировать PEP 0008 (официальное руководство по стилю Python), так как он комментирует эту проблему в скромной длине:
Обратите внимание на «не ограничено» в приведенной выше цитате; Помимо подходов, предложенных в руководстве по стилю, некоторые из предложенных в других ответах на этот вопрос также приемлемы.
источник
Вот что я делаю, помните, что «все» и «любой» принимает итерируемое, поэтому я просто помещаю длинное условие в список и позволяю «всем» делать работу.
источник
Я удивлен, что не вижу своего предпочтительного решения,
Поскольку
and
это ключевое слово, оно выделяется моим редактором и выглядит достаточно отличающимся от do_something под ним.источник
Добавляя к тому, что сказал @krawyoti ... Длинные условия пахнут, потому что они трудны для чтения и трудны для понимания. Использование функции или переменной делает код более понятным. В Python я предпочитаю использовать вертикальное пространство, заключать в скобки и размещать логические операторы в начале каждой строки, чтобы выражения не выглядели как «плавающие».
Если условия необходимо оценивать более одного раза, как в
while
цикле, то лучше использовать локальную функцию.источник
Лично мне нравится добавлять смысл в длинные операторы if. Мне пришлось бы искать в коде, чтобы найти подходящий пример, но вот первый пример, который приходит на ум: допустим, я случайно натолкнулся на какую-то странную логику, где я хочу отобразить определенную страницу в зависимости от многих переменных.
Английский: «Если вошедший в систему пользователь НЕ является учителем-администратором, а просто обычным учителем и не является самим студентом ...»
Конечно, это может выглядеть хорошо, но читать их, если заявления много работы. Как насчет того, чтобы мы присвоили логику метке, которая имеет смысл. «Метка» - это имя переменной:
Это может показаться глупым, но у вас может быть еще одно условие, когда вы ТОЛЬКО хотите отображать другой элемент, если и только если вы отображаете панель учителя ИЛИ, если у пользователя есть доступ к этой другой конкретной панели по умолчанию:
Попробуйте написать вышеупомянутое условие, не используя переменные для хранения и маркировки вашей логики, и вы не только получите очень грязное, трудно читаемое логическое утверждение, но вы также просто повторили себя. Хотя есть разумные исключения, помните: не повторяйте себя (СУХОЙ).
источник
«all» и «any» хороши для многих условий одного типа. НО они всегда оценивают все условия. Как показано в этом примере:
источник
all()
то время, если вы не собираетесь обернуть их каждое в лямбду и использовать свойf()
трюк, все они будут оценены. Другими словами, Аарон: я думаю, что Андерс пытался говорить об условиях в целом, используя в качестве конкретного примера вызываемые объекты; но ваш ответ относится только к функциям.(Я слегка изменил идентификаторы, так как имена с фиксированной шириной не представляют реальный код - по крайней мере, реальный код, с которым я сталкиваюсь - и будут полагаться на читаемость примера.)
Это хорошо работает для «и» и «или» (важно, чтобы они были первыми во второй строке), но гораздо меньше для других длительных условий. К счастью, первое, кажется, является более распространенным случаем, в то время как второе часто легко переписывается с помощью временной переменной. (Обычно это не сложно, но может быть трудно или гораздо менее очевидно / читабельно сохранить короткое замыкание «и» / «или» при перезаписи.)
Так как я нашел этот вопрос в вашем блоге о C ++ , я добавлю, что мой стиль C ++ идентичен:
источник
Простой и простой, также проходит проверку pep8:
В последнее время я предпочитая
all
иany
функции, так как я редко смешиваются И и Или сравнения это работает хорошо, и имеет дополнительное преимущество При отсутствии Early с генераторами понимания:Просто не забудьте пройти в одной итерации! Передача N-аргументов неверна.
Примечание:
any
как и многиеor
сравнения,all
как и многиеand
сравнения.Это прекрасно сочетается с пониманием генератора, например:
Больше на: понимание генератора
источник
Что если мы вставим только дополнительную пустую строку между условием и телом и сделаем все остальное каноническим способом?
PS Я всегда использую табуляции, а не пробелы; Я не могу точно настроить ...
источник
and
иor
заявления должны начать на следующей строкеЧто я обычно делаю, это:
таким образом закрывающая скобка и двоеточие визуально обозначают конец нашего состояния.
источник
and
илиor
.Все респонденты, которые также предоставляют мультиусловия для утверждения if, столь же безобразны, как и представленная проблема. Вы не решаете эту проблему, делая то же самое ..
Даже ответ PEP 0008 отталкивающий.
Вот гораздо более читаемый подход
Хочешь, чтобы я съел мои слова? Убедите меня, что вам нужны мультиусловия, и я буквально напечатаю это и съест это для вашего удовольствия.
источник
Я думаю, что решение @ zkanda было бы хорошо с небольшим поворотом. Если бы у вас были свои условия и значения в их соответствующих списках, вы могли бы использовать понимание списка для сравнения, что сделало бы вещи более общими для добавления пар условие / значение.
Если бы я захотел жестко запрограммировать такое утверждение, я бы написал это для удобочитаемости:
И просто добавьте другое решение с
iand
оператором :источник
all(map(eq, have, expected))
. (сfrom operator import eq
)Просто несколько других случайных идей для полноты картины. Если они работают на вас, используйте их. В противном случае вам, вероятно, лучше попробовать что-то другое.
Вы также можете сделать это с помощью словаря:
Эта опция более сложная, но вы также можете найти ее полезной:
Не знаю, если это работает для вас, но это еще один вариант для рассмотрения. Вот еще один способ:
Последние два я не проверял, но концепций должно быть достаточно, чтобы вы начали, если вы хотите этого.
(И для справки: если это всего лишь один раз, возможно, вам лучше использовать метод, который вы представили сначала. Если вы проводите сравнение во многих местах, эти методы могут улучшить читабельность, достаточную для Вы не чувствуете себя так плохо по поводу того, что они отчасти хакеры.)
источник
Я изо всех сил пытался найти достойный способ сделать это, поэтому я просто пришел с идеей (не серебряная пуля, так как это в основном дело вкуса).
Я нашел несколько достоинств в этом решении по сравнению с другими, которые я видел, а именно, вы получаете ровно дополнительные 4 пробела отступа (bool), позволяя всем условиям выстраиваться вертикально, а тело оператора if может быть смещено в ясный путь Это также сохраняет преимущества оценки коротких замыканий логических операторов, но, конечно, добавляет накладные расходы при вызове функции, которая в основном ничего не делает. Вы могли бы утверждать (действительно), что любая функция, возвращающая свой аргумент, могла бы использоваться здесь вместо bool, но, как я уже сказал, это всего лишь идея, и в конечном итоге это вопрос вкуса.
Как ни странно, когда я писал это и думал о «проблеме», у меня появилась еще одна идея, которая устраняет накладные расходы при вызове функции. Почему бы не указать, что мы собираемся ввести сложное условие, используя дополнительные пары скобок? Скажем, еще 2, чтобы получить хороший 2 пробела для подусловий относительно тела оператора if. Пример:
Мне это нравится, потому что, когда вы смотрите на это, в вашей голове немедленно звонит колокольчик, говоря: «Эй, здесь происходит сложная вещь!» , Да, я знаю, что круглые скобки не помогают читабельности, но эти условия должны появляться достаточно редко, и когда они все-таки появятся, вам в любом случае придется остановиться и прочитать их осторожно (потому что они сложные ).
Во всяком случае, еще два предложения, которые я не видел здесь. Надеюсь, это поможет кому-то :)
источник
Вы можете разбить его на две строки
Или даже добавить по одному условию за раз. Таким образом, по крайней мере, это отделяет беспорядок от
if
.источник
Я знаю, что эта ветка старая, но у меня есть немного кода Python 2.7, и PyCharm (4.5) все еще жалуется на этот случай:
Даже с предупреждением PEP8 «визуально с отступом строки с тем же отступом, что и у следующей логической строки», фактический код полностью в порядке? Это не "чрезмерный отступ?"
... бывают моменты, когда я хотел бы, чтобы Python укусил пулю и просто ушел с фигурными скобками. Интересно, сколько ошибок было случайно введено за эти годы из-за случайного неверного отступа ...
источник
Упакуйте свои условия в список, затем сделайте что-нибудь. подобно:
источник
Я нахожу, что когда у меня длинные условия, у меня часто короткое тело кода. В этом случае я просто делаю двойной отступ в теле, таким образом:
источник
или если это понятнее:
Нет никаких причин, по которым отступ должен быть кратен 4 в этом случае, например, см. «Выровнено по открывающему разделителю»:
http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Indentation#Indentation
источник
Вот еще один подход:
Это также позволяет легко добавить другое условие без изменения оператора if, просто добавив другое условие в список:
источник
Я обычно использую:
источник
Если наше условие if & else должно выполнить несколько операторов внутри него, мы можем написать, как показано ниже. Каждый раз, когда у нас есть, если еще пример с одним утверждением внутри него.
Спасибо, это работает для меня.
источник
Прошу прощения за мою нелюбовь, но бывает, что я не так хорошо разбираюсь в #Python, как кто-либо из вас здесь, но бывает, что я обнаружил нечто подобное при написании сценариев своих собственных объектов в 3D BIM-моделировании, поэтому я адаптирую свой алгоритм к что из питона.
Проблема, которую я нахожу здесь, является двусторонней:
Чтобы обойти все эти проблемы, ваш скрипт должен идти так
Плюсы этого метода:
Скрипт читабелен.
Сценарий может быть легко поддерживается.
Надеюсь, это поможет вам всем
источник