2010-04-28 37 views
29

哪个是首选(“。”表示空白)?“空行”中的Python缩进

A)

def foo(): 
    x = 1 
    y = 2 
.... 
    if True: 
     bar() 

B)

def foo(): 
    x = 1 
    y = 2 

    if True: 
     bar() 

我的直觉是B(这也是什么VIM做对我来说),但我请参阅使用人)所有的时间。这是否仅仅是因为那里的大部分编辑都被破坏了?

回答

18

PEP 8在这个问题上似乎不太清楚,虽然关于“空白行”的陈述可以被解释为支持B. PEP 8样式检查器(pep8.py)更喜欢B并且在使用时发出警告一个;不过,这两种变化都是合法的。我自己的看法是,既然Python在任何情况下都能成功地解释代码,这并不重要,并且尝试执行它将会有很大的收获。我想,如果你非常坚定地支持这一方,那么你可以自动将这一方转换为另一方。尽管如此,尝试手动修复所有这些线路将是一项艰巨的任务,实际上不值得付出努力,恕我直言。

+8

有好的理由支持A - 复制到shell中,B导致一些编辑出现问题。除非A也存在问题,否则似乎是“A在某些情况下有帮助,不会伤害”的情况,因此应该使用A. – Ted 2013-04-17 17:14:06

+1

's/^([\ t] +)([^ \ r \ n] *)(\ r?\ n)\ r?\ n/\ 1 \ 2 \ 3 \ 1 \ 3 /'。搜索:在行首捕捉制表符或空格,捕获任何非换行符(如果有),捕获换行符,查找换行符*。替换:缩进,行内容,换行符,缩进,换行符。注意:如果缩进行打开一个新块,则正则表达式不会检测到这一点,只是将下一行放在相同的缩进级别。 *我忽略了第二个换行格式,只是使用以前的换行格式来提高一致性 – 2016-08-16 04:41:54

0

Emacs B)对我来说,但我真的不认为它很重要。 A)意味着你可以在没有任何标签的正确缩进处添加一行。

9

该空行属于foo(),所以我认为A是最自然的。但我想这只是一个意见问题。

+0

我同意这更自然,我不同意这是一个意见问题。这是事实。 – 2014-08-31 13:58:08

3

我不一定会称第一个例子为“破碎”,因为我知道有些人在代码中向上或向下移动光标时光标“跳回”时讨厌它。例如。 Visual Studio(至少2008)会自动防止这种情况发生,而不在这些行上使用任何空白字符。

28

如果使用一个,你可以复制粘贴在Python Shell块,将得到意想不到的缩进错误。

+0

我尝试在idlex中使用A,而是得到了无效的语法错误。 – obesechicken13 2013-08-11 16:17:20

+0

版本B在复制/粘贴到iPython时无法正常工作。 – Mitch 2015-05-12 18:56:06

+0

@ obesechicken13这些点应该是空格,它们只是画出来让你知道它们在那里。 – pydsigner 2015-08-11 20:52:27

1

我在开源开发方面的经验是,不应该在空白行内留下空白。也不应该留下拖尾的空白。

这是编码礼仪的问题。

+0

+1:我有我的IDE条尾随空白。 – 2010-04-28 10:19:07

+3

不是缩写像python – 2010-05-03 08:45:52

+1

这样的语言@ Lo'oris Indentation对于代码而言是强制性的,对于空白行则不是。因此空白行中的任何空格都是不必要的。 – 2010-05-10 06:32:52

4

如果您使用B,TextMate会打破块折叠,而且我更喜欢A因为它更“合乎逻辑”。

+0

有趣。我只是用EditPadPro试用它,它也使用缩进级别进行代码折叠,并且它很好地处理空行。 – 2010-04-28 11:50:10

7

添加适当的缩进空白行(风格在问题的)极大地提高了代码的可读性,并启用显示空白,因为它可以更容易看到一个空行之后的代码是否是相同的缩进块与否的一部分。

对于像Python这样的语言,没有结束语句或者括号,我很惊讶这不是PEP的一部分。强烈建议使用显示空格开启编辑Python,以避免尾随空格和混合缩进。

比较阅读以下:

A)

def foo(): 
....x = 1 
....y = 2 
.... 
....if True: 
........bar() 

B)

def foo(): 
....x = 1 
....y = 2 

....if True: 
........bar() 

,它远远更清楚的是,最后两行是foo一部分。这在缩进级别更高的情况下更有用。

0

vi隐含地阻止了A中的行为,因为{/}导航不再按预期工作。 git通过在运行git diff时突出显示它为红色来明确阻止它。我还会争辩说,如果一行包含空格,它不是空行。

因为这个原因,我非常喜欢B.没有什么比期待跳过六个左右排列起来的{动作并最终在类def的顶部更糟糕。