Python PEP8 编码规范中文版.pdf-资料库

65a8f7e1-008b-444f-a308-c07ff6f2e99b.pdf-第1页.png

第1页 / 共34页

65a8f7e1-008b-444f-a308-c07ff6f2e99b.pdf-第2页.png

第2页 / 共34页

65a8f7e1-008b-444f-a308-c07ff6f2e99b.pdf-第3页.png

第3页 / 共34页

65a8f7e1-008b-444f-a308-c07ff6f2e99b.pdf-第4页.png

第4页 / 共34页

65a8f7e1-008b-444f-a308-c07ff6f2e99b.pdf-第5页.png

第5页 / 共34页

65a8f7e1-008b-444f-a308-c07ff6f2e99b.pdf-第6页.png

第6页 / 共34页

65a8f7e1-008b-444f-a308-c07ff6f2e99b.pdf-第7页.png

第7页 / 共34页

65a8f7e1-008b-444f-a308-c07ff6f2e99b.pdf-第8页.png

第8页 / 共34页

Python PEP8 编码规范中文版 Introduction 介绍本文提供的 Python 代码编码规范基于 Python 主要发行版本的标准库。Python 的 C 语言实现的 C 代码规范请查看相应的 PEP 指南 1。这篇文档以及 PEP 257（文档字符串的规范）改编自 Guido 原始的《Python Style Guide》一文，同时添加了一些来自 Barry 的风格指南 2。这篇规范指南随着时间的推移而逐渐演变，随着语言本身的变化，过去的约定也被淘汰了。许多项目有自己的编码规范，在出现规范冲突时，项目自身的规范优先。 A Foolish Consistency is the Hobgoblin of Little Minds 尽信书,则不如无书 Guido 的一条重要的见解是代码阅读比写更加频繁。这里提供的指导原则主要用于提升代码的可读性，使得在大量的 Python 代码中保持一致。就像 PEP 20 提到的， “Readability counts”。这是一份关于一致性的风格指南。这份风格指南的风格一致性是非常重要的。更重要的是项目的风格一致性。在一个模块或函数的风格一致性是最重要的。

然而，应该知道什么时候应该不一致，有时候编码规范的建议并不适用。当存在模棱两可的情况时，使用自己的判断。看看其他的示例再决定哪一种是最好的，不要羞于发问。特别是不要为了遵守 PEP 约定而破坏兼容性！几个很好的理由去忽略特定的规则： 1. 当遵循这份指南之后代码的可读性变差，甚至是遵循 PEP 规范的人也觉得可读性差。 2. 与周围的代码保持一致（也可能出于历史原因），尽管这也是清理他人混乱（真正的 Xtreme Programming 风格）的一个机会。 3. 有问题的代码出现在发现编码规范之前，而且也没有充足的理由去修改他们。 4. 当代码需要兼容不支持编码规范建议的老版本 Python。 Code lay-out 代码布局 Indentation 缩进每一级缩进使用 4 个空格。续行应该与其包裹元素对齐，要么使用圆括号、方括号和花括号内的隐式行连接来垂直对齐，要么使用挂行缩进对齐 3。当使用挂行缩进时，应该考虑到第一行不应该有参数，以及使用缩进以区分自己是续行。推荐：

# 与左括号对齐 foo = long_function_name(var_one, var_two, var_three, var_four) # 用更多的缩进来与其他行区分 def long_function_name( var_one, var_two, var_three, var_four): print(var_one) # 挂行缩进应该再换一行 foo = long_function_name( var_one, var_two, var_three, var_four) 不推荐： # 没有使用垂直对齐时，禁止把参数放在第一行 foo = long_function_name(var_one, var_two, var_three, var_four) # 当缩进没有与其他行区分时，要增加缩进 def long_function_name( var_one, var_two, var_three, var_four): print(var_one) 四空格的规则对于续行是可选的。可选：

# 挂行缩进不一定要用 4 个空格 foo = long_function_name( var_one, var_two, var_three, var_four) 当 if 语句的条件部分长到需要换行写的时候，注意可以在两个字符关键字的连接处（比如 if），增加一个空格，再增加一个左括号来创造一个 4 空格缩进的多行条件。这会与 if 语句内同样使用 4 空格缩进的代码产生视觉冲突。PEP 没有明确指明要如何区分 i 发的条件代码和内嵌代码。可使用的选项包括但不限于下面几种情况： # 没有额外的缩进 if (this_is_one_thing and that_is_another_thing): do_something() # 增加一个注释，在能提供语法高亮的编辑器中可以有一些区分 if (this_is_one_thing and that_is_another_thing): # Since both conditions are true, we can frobnicate. do_something() # 在条件判断的语句添加额外的缩进 if (this_is_one_thing and that_is_another_thing): do_something()

（可以参考下面关于是否在二进制运算符之前或之后截断的讨论）在多行结构中的大括号/中括号/小括号的右括号可以与内容对齐单独起一行作为最后一行的第一个字符，就像这样： my_list = [ 1, 2, 3, 4, 5, 6, ] result = some_function_that_takes_arguments( 'a', 'b', 'c', 'd', 'e', 'f', ) 或者也可以与多行结构的第一行第一个字符对齐，就像这样： my_list = [ 1, 2, 3, 4, 5, 6, ] result = some_function_that_takes_arguments( 'a', 'b', 'c', 'd', 'e', 'f', ) Tabs or Spaces？制表符还是空格？空格是首选的缩进方式。制表符只能用于与同样使用制表符缩进的代码保持一致。 Python3 不允许同时使用空格和制表符的缩进。

混合使用制表符和空格缩进的 Python2 代码应该统一转成空格。当在命令行加入-t 选项执行 Python2 时，它会发出关于非法混用制表符与空格的警告。当使用–tt 时，这些警告会变成错误。强烈建议使用这样的参数。 Maximum Line Length 行的最大长度所有行限制的最大字符数为 79。没有结构化限制的大块文本（文档字符或者注释），每行的最大字符数限制在 72。限制编辑器窗口宽度可以使多个文件并行打开，并且在使用代码检查工具(在相邻列中显示这两个版本)时工作得很好。大多数工具中的默认封装破坏了代码的可视化结构，使代码更难以理解。避免使用编辑器中默认配置的 80 窗口宽度，即使工具在帮你折行时在最后一列放了一个标记符。某些基于 Web 的工具可能根本不提供动态折行。一些团队更喜欢较长的行宽。如果代码主要由一个团队维护，那这个问题就能达成一致，可以把行长度从 80 增加到 100 个字符（更有效的做法是将行最大长度增加到 99 个字符），前提是注释和文档字符串依然已 72 字符折行。 Python 标准库比较保守，需要将行宽限制在 79 个字符（文档/注释限制在 72）。较长的代码行选择 Python 在小括号，中括号以及大括号中的隐式续行方式。通过小括号内表达式的换行方式将长串折成多行。这种方式应该优先使用，而不是使用反斜杠续行。反斜杠有时依然很有用。比如，比较长的，多个 with 状态语句，不能使用隐式续行，所以反斜杠是可以接受的： with open('/path/to/some/file/you/want/to/read') as file_1, \ open('/path/to/some/file/being/written', 'w') as file_2:

file_2.write(file_1.read()) （请参阅前面关于多行 if-语句的讨论，以获得关于这种多行 with-语句缩进的进一步想法。）另一种类似情况是使用 assert 语句。确保在续行进行适当的缩进。 Should a line break before or after a binary operator? 在二元运算符之前应该换行吗？几十年来，推荐的风格是在二元运算符之后中断。但是这回影响可读性，原因有二：操作符一般分布在屏幕上不同的列中，而且每个运算符被移到了操作数的上一行。下面例子这个情况就需要额外注意，那些变量是相加的，那些变量是相减的： # 不推荐: 操作符离操作数太远 income = (gross_wages + taxable_interest + (dividends - qualified_dividends) - ira_deduction - student_loan_interest) 为了解决这种可读性的问题，数学家和他们的出版商遵循了相反的约定。Donald Knuth 在他的 Computers and Typesetting 系列中解释了传统规则：“尽管段落中的公式总是在二元运算符和关系之后中断，显示出来的公式总是要在二元运算符之前中断”4。遵循数学的传统能产出更多可读性高的代码： # 推荐：运算符和操作数很容易进行匹配 income = (gross_wages + taxable_interest + (dividends - qualified_dividends) - ira_deduction

- student_loan_interest) 在 Python 代码中，允许在二元运算符之前或之后中断，只要本地的约定是一致的。对于新代码，建议使用 Knuth 的样式。 Blank Lines 空行顶层函数和类的定义，前后用两个空行隔开。类里的方法定义用一个空行隔开。相关的功能组可以用额外的空行（谨慎使用）隔开。一堆相关的单行代码之间的空白行可以省略（例如，一组虚拟实现 dummy implementations）。在函数中使用空行来区分逻辑段（谨慎使用）。 Python 接受 control-L（即^L）换页符作为空格；许多工具把这些字符当作页面分隔符，所以你可以在文件中使用它们来分隔相关段落。请注意，一些编辑器和基于 Web 的代码阅读器可能无法识别 control-L 为换页，将在其位置显示另一个字形。 Source File Encoding 源文件编码 Python 核心发布版本中的代码总是以 UTF-8 格式编码（或者在 Python2 中用 ASCII 编码）。使用 ASCII（在 Python2 中）或 UTF-8（在 Python3 中）编码的文件不应具有编码声明。在标准库中，非默认的编码应该只用于测试，或者当一个注释或者文档字符串需要提及一个包含内 ASCII 字符编码的作者名字的时候；否则，使用\x,\u,\U , 或者 \N 进行转义来包含非 ASCII 字符。对于 Python 3 和更高版本，标准库规定了以下策略（参见 PEP 3131）：Python 标准库中的所有标识符必须使用 ASCII 标识符，并在可行的情况下使用英语单词（在许

资料库

Python PEP8 编码规范中文版.pdf

相关推荐

后端

热门标签

最新资料