有时我会把if中的长条件分解成几行。最明显的方法是：
if (cond1 == 'val1' and cond2 == 'val2' and
cond3 == 'val3' and cond4 == 'val4'):
do_something
视觉上不是很吸引人，因为动作与环境融为一体。然而，这是使用4个空格的正确Python缩进的自然方式。
目前我正在使用：
if ( cond1 == 'val1' and cond2 == 'val2' and
cond3 == 'val3' and cond4 == 'val4'):
do_something
但这不是很漂亮
你能推荐另一种方法吗？
当前回答
这是我个人的看法：长条件（在我看来）是一种代码气味，建议重构为布尔返回函数/方法。例如：
def is_action__required(...):
return (cond1 == 'val1' and cond2 == 'val2'
and cond3 == 'val3' and cond4 == 'val4')
现在，如果我找到了一种让多行条件看起来很好的方法，我可能会发现自己满足于拥有它们，并跳过重构。
另一方面，让它们扰乱了我的审美意识，这是一种重构的激励。
因此，我的结论是，多行条件应该看起来很难看，这是避免它们的一种激励。
其他回答
我建议将和关键字移到第二行，并用两个空格而不是四个空格缩进包含条件的所有行：
if (cond1 == 'val1' and cond2 == 'val2'
and cond3 == 'val3' and cond4 == 'val4'):
do_something
这正是我在代码中解决这个问题的方法。将关键字作为行中的第一个单词可以使条件更加可读，并且减少空格的数量可以进一步区分条件和操作。
我知道这个线程很旧，但我有一些Python 2.7代码，PyCharm（4.5）仍然抱怨这个例子：
if foo is not None:
if (cond1 == 'val1' and cond2 == 'val2' and
cond3 == 'val3' and cond4 == 'val4'):
# some comment about do_something
do_something
即使有PEP8警告“视觉缩进的行与下一个逻辑行缩进相同”，实际代码也完全正常？这不是“过度缩进？”
……有时我希望Python能咬紧牙关，只带上大括号。我想知道这些年来有多少错误是由于错误的缩进而被意外引入的。。。
这是我个人的看法：长条件（在我看来）是一种代码气味，建议重构为布尔返回函数/方法。例如：
def is_action__required(...):
return (cond1 == 'val1' and cond2 == 'val2'
and cond3 == 'val3' and cond4 == 'val4')
现在，如果我找到了一种让多行条件看起来很好的方法，我可能会发现自己满足于拥有它们，并跳过重构。
另一方面，让它们扰乱了我的审美意识，这是一种重构的激励。
因此，我的结论是，多行条件应该看起来很难看，这是避免它们的一种激励。
（我对标识符进行了轻微修改，因为固定宽度的名称不能代表真实代码——至少不能代表我遇到的真实代码——并且会掩盖示例的可读性。）
if (cond1 == "val1" and cond22 == "val2"
and cond333 == "val3" and cond4444 == "val4"):
do_something
这适用于“和”和“或”（重要的是它们位于第二行的第一位），但对于其他较长的条件就更不适用了。幸运的是，前者似乎是更常见的情况，而后者往往很容易用临时变量重写。（这通常不难，但在重写时保持“和”/“或”的短路可能很难或不那么明显/可读。）
由于我在你的关于C++的博客文章中发现了这个问题，我将补充我的C++风格是相同的：
if (cond1 == "val1" and cond22 == "val2"
and cond333 == "val3" and cond4444 == "val4") {
do_something
}
当我有一个非常大的if条件时，我更喜欢这种风格：
if (
expr1
and (expr2 or expr3)
and hasattr(thingy1, '__eq__')
or status=="HappyTimes"
):
do_stuff()
else:
do_other_stuff()
