用于删除多行"if"语句的代码风格?

Thi*_*ter 34 python coding-style indentation code-readability

如果在条件下缩进很长时间,你通常会做这样的事情(实际上,PyDev会这样缩进):

if (collResv.repeatability is None or
    collResv.somethingElse):
    collResv.rejected = True
    collResv.rejectCompletely()
Run Code Online (Sandbox Code Playgroud)

但是,这会将if语句启动的块放在与if条件的最后一部分相同的缩进级别上,这使得它在我看来非常难看/难以阅读,因为您没有立即看到块的开始位置.

我想到的其他一些风格:

if (collResv.repeatability is None or
        collResv.somethingElse):
    collResv.rejected = True
    collResv.rejectCompletely()
Run Code Online (Sandbox Code Playgroud)

这看起来非常不一致,因为第二行缩进比第一行缩进得多,但它是可读的.

if (collResv.repeatability is None or
  collResv.somethingElse):
    collResv.rejected = True
    collResv.rejectCompletely()
Run Code Online (Sandbox Code Playgroud)

这也比第一个例子更具可读性,但缩进不再是4的倍数,而且它看起来不对,因为第二行的缩进比第一行中条件的开头少.


所以,我的主要问题是:对于那些不需要过长行(即单行条件)的情况,是否有建议的缩进样式?如果没有,更喜欢这样的情况?

Obe*_*nne 23

我经常通过计算自己语句中的条件来解决这个问题:

condition = (collResv.repeatability is None or
             collResv.somethingElse)
if condition:
    collResv.rejected = True
    collResv.rejectCompletely()
Run Code Online (Sandbox Code Playgroud)

虽然,对于一个相对较短的情况,如你的具体例子,我会选择nosklo的解决方案 - 这里使用的额外声明更适合更长的条件表达式.


nos*_*klo 13

这就是我做的:

if (collResv.repeatability is None or
        collResv.somethingElse):
    collResv.rejected = True
    collResv.rejectCompletely()
Run Code Online (Sandbox Code Playgroud)


Rei*_*und 12

这里所有先前建议的一个问题是后续条件的逻辑运算符被放在前一行.Imo,这使得它的可读性降低.

我建议将逻辑运算符放在与if语句附加的条件相同的行上.

在我看来,这更好

if (None == foo
        and None == bar
        or None == foo_bar):
Run Code Online (Sandbox Code Playgroud)

比这个:

if (None == foo and
        None == bar or
        None == foo_bar):
Run Code Online (Sandbox Code Playgroud)

  • 提出的问题之一是“ ...您喜欢这样的情况吗?” 我的回答回答了这个问题,而不仅仅是一个评论。 (2认同)
  • 实际上,这不仅仅是关于缩进的问题。问题还涉及OP明确关心的代码样式和代码的易读性。 (2认同)

Gle*_*ard 9

这是一个间接的答案 - 不直接回答风格问题,但这是一般的实际答案,所以值得一提.

我发现需要编写多行条件非常罕见.这有两个因素:

  • 不要将代码包装在80列.PEP-8关于这个问题的建议是古老而有害的; 我们已经过了80x25终端和编辑器的时代,这些终端和编辑器无法合理地处理包装.100列很好,120也是可以接受的.
  • 如果条件变得太长以至于它们仍然需要换行,那么将一些逻辑移出条件并进入单独的表达式通常是合理的.这也有助于提高可读性.

通过我最近的项目,大约12kloc,只有一个条件足够长,需要包装; 这个问题很少出现.如果你确实需要这样做,那么就像nosklo所说的那样,单独缩进它 - 正如你所注意到的那样,将它缩进到与它下面的块相同的水平是令人困惑和难以阅读的.

  • 一般我同意,尽管仍然有充分的理由坚持80列(眼睛喜欢宽度有限的文字;可以并排处理多个文件). (27认同)
  • 只要一个开发人员使用超长线 - 认为200-char线或其他任何东西都不必在今天的屏幕上包装 - 其他一些开发人员现在不能将三个窗口并排放在监视器上并看到格式合理的代码.超过80个cols与在其他开发者身上造成未包装的代码基本相同 - 它与散文文本无关.仅仅因为给定的作者不能并排放置两个80列编辑器并不意味着没有其他人想要(虽然一些需要大字体大小的开发人员很容易阅读,这是对长函数的一个很好的论据......并且很长行) (8认同)