您忽略了哪些PEP 8指南,以及您坚持哪些？

Question

多年来,我写的Python越多,我就越发现自己同意大多数指导方针,尽管我一直并故意为了自己的原因打破了一些.

我很想知道PEP 8(或其他PEP也可能)人们虔诚地坚持和为什么,以及人们发现不方便或不足的内容.

在我的情况下(以及一般的工作),我们只有少数几个偏离的东西:

• 下划线小写名称,我可以看到它的重点,因为它将始终保持一致,但我们倾向于使用lowerCamelCase,即使它偶尔会引入一些不一致性(例如部分或错误大写的首字母缩略词和跟随的词,这是经常下降到一时冲动的电话).主要是因为我们经常使用的近乎全部的API使用camelCase(一些较高,一些较低),并且由于某种原因我发现它更容易阅读,并且倾向于将下划线保留为分离令牌或规定的修改/模糊.

• 我仍然无法让自己按照PEP规定的内容来解决问题.new和init我倾向于在类下面没有空行,因为我总是希望用类名和args读取它们,这些方法有助于类中相同的功能范围(比如init,get和set)同一个attrib或一组attribs)我只分开单个空格,我喜欢类之间的三个空格,两个方法之间我不会在该对象的地图中进行心理聚合.这再次纯粹是为了代码的视觉冲击和可读性.我发现流量控制中的内容非常紧凑,方法和物体之间的这种间距一直引起我的注意,我希望它在代码停放几个月后重新读取.

• 有些事情反而是我坚持,当我阅读其他文字时,这让我疯狂,是标签而不是空格(特别是当我们使用的一些应用程序内编辑器没有真正具有标签替换功能时,对代码库中的污染造成很大影响)原型设计阶段).

• 诸如导入之类的东西的顺序,以及什么是导入,全局变换等等.当这些文件混合或乱序时,它真的会抛弃那些具有大量导入的文件.

• 语句中的空格,特别是当人们使用制表符并尝试在var名称中跨越不同长度的行对齐赋值操作时(并且似乎没有办法说服那些做excel看起来代码片段的人不整齐;)) .

• 并且在控制块内的间距,特别是当我在同一流控制块内看到明显随机的间距,然后在对象内使用类似的间距用于方法时.在我开始读这该死的东西之前,我不得不编辑那些.

所以,那些是我的,以及我"违反"PEP背后的原因(有些是共享的,有些是同事不赞同的).我很想知道其他Pythonistas在这方面做了什么和不做什么.

Answer 1

"每行79个字符"部分是无稽之谈.他们自己的例子显示了执行此操作时代码的不可读性:

class Rectangle(Blob):

    def __init__(self, width, height,
                 color='black', emphasis=None, highlight=0):
        if width == 0 and height == 0 and \
           color == 'red' and emphasis == 'strong' or \
           highlight > 100:
            raise ValueError("sorry, you lose")
        if width == 0 and height == 0 and (color == 'red' or
                                           emphasis is None):
            raise ValueError("I don't think so -- values are %s, %s" %
                             (width, height))
        Blob.__init__(self, width, height,
                      color, emphasis, highlight)

这就像试戴
ING阅读
新闻arti-
书面CLE
这样.

十多年来,80列终端并不是一个严肃的开发环境.当我确实需要在瘫痪的80x25环境中进行编辑时,编辑器包装是一个小小的不便; 为了避免这种情况,我不会在正常开发期间破坏我的代码.

120列包装对于现代开发是完全合理的,我对140没有任何问题.该指南已经过时,并且会导致难以读取的难以阅读的代码.

Answer 2

PEP8表示要避免"在赋值(或其他)操作符周围有多个空格将它与另一个操作符对齐"并且"从不使用多个空格"围绕数学运算符,但我不遵循这一点.

当相邻行相关或非常相似时,我经常添加"无关的空白",但不完全相同:

search_start = (f - f_1/3) * n/fs
search_stop  = (f + f_1/3) * n/fs

 

b_lpf, a_lpf = filter(N, 2*pi*fc, 'low',  analog=True)
b_hpf, a_hpf = filter(N, 2*pi*fc, 'high', analog=True)

 

p[x >  1] =                         np.cosh(order * np.arccosh( x[x >  1]))
p[x < -1] = (1 - 2 * (order % 2)) * np.cosh(order * np.arccosh(-x[x < -1]))

 

b0 =  (1 + cos(w0))/2
b1 = -(1 + cos(w0))

同样,令人讨厌的是,我获得了数字数组的代码样式警告,这些数字以可读方式格式化,通常由库本身格式化:

a = array([[-0.198,  0.248, -1.17 , -0.629,  1.378],
           [-1.315,  0.947, -0.736, -1.388,  0.389],
           [ 0.241, -0.98 ,  0.535,  0.951,  1.143],
           [-0.601,  1.286, -0.947,  0.037, -0.864],
           [ 0.178, -0.289, -1.037, -1.453, -0.369]])

PEP8宁愿让它像这样格式化,显然,因为我们在逗号之前或括号之后不能有额外的空格:

a = array([[-0.198, 0.248, -1.17, -0.629, 1.378],
           [-1.315, 0.947, -0.736, -1.388, 0.389],
           [0.241, -0.98, 0.535, 0.951, 1.143],
           [-0.601, 1.286, -0.947, 0.037, -0.864],
           [0.178, -0.289, -1.037, -1.453, -0.369]])

Answer 3

PEP8说

请注意,最重要的是,结束多行文档字符串的"""应该在一行上,并且最好以空行开头,例如:

"""Return a foobang

Optional plotz says to frobnicate the bizbaz first.

"""

我觉得这很奇怪,因为它只是"无关的空白",并且没有明显的原因,对开场报价的处理与报价不同.

PEP 257给出了一个基本原理:

BDFL建议在多行文档字符串中的最后一个段落与其结束引号之间插入一个空行,将结束引号放在一行上.这样,可以在其上使用Emacs的fill-paragraph命令.

Emacs,真的吗？每个人都应该做一些奇怪的事情来迎合特定编辑工具中特定命令的特性？

我还认为将文档字符串的开头放在与引号相同的行(不是必需的,但建议的)上是很奇怪的,同时坚持将结束引用放在他们自己的行上.我认为这更符合逻辑,应该用于单行和多行文档字符串:

def foobang(bizbaz, plotz=None):
    """
    Return a foobang

    Optional plotz says to frobnicate the bizbaz first.
    """

    if plotz is not None:
        ...

更新:粗体部分已被删除,现在它只是说"将结束引号单独放在一行",并且"汇总行可能与开头报价在同一行或在下一行".

Answer 4

我不同意这点:

- Imports should usually be on separate lines, e.g.:

    Yes: import os
         import sys

    No:  import sys, os

我总是一起写简单的进口.我认为将它们全部写在不同的行上并没有任何好处:它所做的只是在每个源文件的顶部添加膨胀,并将一些简洁的东西变成简单易用的东西,例如边界样板.一些非常冗长的东西,它开始很容易从其他文件中复制和粘贴.

这是立即可读和可理解的:

import sys, os, time, gc, inspect, math, doctest

它简短,易于浏览,易于添加.import如果一行中有太多,当然或者我需要from导入,我会使用多个语句.

我也做一般保持标准库进口的我自己的模块进口和其他库的独立,这与分组PEP8建议的概念一致.

Answer 5

标准至关重要,PEP 8是我坚持的非常好的风格指南.我不同意的唯一指导是数学运算符周围的间距.例如,PEP8坚持以下间距

Without PEP8                           With PEP8                
---------------------------------------------------------------- 
y = sqrt(x**2 + y**2)                  y = sqrt(x ** 2 + y ** 2) 
a*x**3 + b*x**2 + c*x + d              a * x ** 3 + b * x ** 2 + c * x + d 
10**(a*x + b)                          10 ** (a * x + b)  
F = V/(sqrt(g*h) + epsilon)            F = V / (sqrt(g * h) + epsilon) 
a*cos(nx/pi) + b*sin(nx/pi)            a * cos(nx / pi) + b * sin(nx / pi) 

我想要顺从,但这是我正在努力的一个领域.还有其他人也觉得PEP8间距让数学难以阅读吗？

更新:

PEP8被纠正建议的格式左侧,同时阻止右侧的格式:

是:

i = i + 1
submitted += 1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)

没有:

i=i+1
submitted +=1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)

Answer 6

我公司的风格指南专门要求标签,而不是空格.PEP 8暗示空间是可取的,但我们发现了相反的情况.我喜欢在VIM中看到代码缩进4个"空格",同事喜欢Emacs中的8个"空格".使用选项卡可以让我们设置编辑器以显示我们喜欢的代码.

请注意,在其他基于C语言中,缩进实际上只是格式化,但在Python 缩进中是语法,因此我们认为indentation level 2应该由2某些东西(即制表符)表示,4或者8某些东西(即空格).

缩进字符选择可能是最初的圣火焰战争(甚至在VIM/Emacs火焰战争之前),所以我确实希望被修改为遗忘以表达对该主题的意见!

Answer 7

我的“承认违规”是关于“如果”

PEP8 在一行中没有说多个语句，所以如果我们必须这样做：

if cond:
    actions
    ...

但是当只有一个动作时，我更喜欢一行，例如我更喜欢：

if a == 0: b = 0

比：

if a == 0:
     b = 0

Answer 8

多行条件等：PEP-8 明确表示在二元运算符之后而不是之前中断。恐怕我看不出这有什么吸引力。对我来说，在条件之前中断更有意义，因此在换行/连续行中，每个子行都以条件开头：

if (condition1 \
        or condition2 \
        or condition3):
    do_something()

可以看出，我还喜欢为子行添加额外的缩进，以便它们在视觉上与下面的块有偏移。PEP-8 没有明确说明这一点（是吗？），但示例中的子行与左括号对齐。

Answer 9

PEP 8 的“问题”在于它涉及个人偏好的领域，而这些领域对大多数程序员来说都非常情绪化。

就我个人而言，驼峰式与下划线和列对齐指令是经常出现的问题。我也在这里看到了许多其他回复的观点，有时我故意破坏 PEP 8，因为在这种特殊情况下它只是“有意义”。

当我放弃并转向（使用）PEP 8 时，在我的 Python 编程生涯中有一点。对于大多数项目来说，这相对容易，所以现在我唯一的主要问题是列对齐。那个太乱了，不能服从（尽管我很讨厌这样做）。无论如何，由于我的“放弃”，我的代码现在对我的同事更具可读性 - 而且 - 令人惊讶的是：甚至对我来说也是如此（除了列对齐 :p ）。

我还必须认识到 PEP 8 为 python 本身做了什么：在 2.x（不兼容）和 3.x（兼容）之间，我发现“始终知道”特定函数的名称要容易得多。Python 的“电池”现在分类更好了。

Answer 10

当我编写小脚本时，我经常只使用两个空格。

我总是对文档字符串使用相同的模式：

def function():
    """
    Even if it's a single line.
    """