Python 代码风格指南.docx

Python 代码风格指南 介绍 本文档所提供的编码规范，适用于主要的Python发行版中组成标准库的Python代码。请参阅PEP关于Python的C实现的C编码风格指南的描述。 本文档和PEP257（文档字符串规范）改编自Guido的《Python Style Guide》一文，并从《Barrys style guide》添加了部分内容作为补充。 这篇风格指南随着时间的推移而逐渐演变，随着语言本身的变化，一些过去的约定已经过时，并确定了更多新的约定。 许多项目都有自己的编码风格指南。如果有任何冲突，优先使用该项目特定的指南。 愚蠢地坚持一致性是无知的妖怪 Guido的一个重要的见解是，代码阅读的次数比编写的次数多。这里提供的指南旨在提高代码的可读性，并使各种不同的Python代码一致。如PEP20所说，“易读性非常重要”。 风格指南是关于一致性的。与本风格指南一致很重要。项目中的一致性更重要。一个模块或功能中的一致性最重要。 最重要的是：知道何时会不一致——有时风格指南就不适用了。怀疑时，作出你最佳的判断。看看其他的例子，并决定什么是最好的。不要犹豫，尽管发问！ 特别地：不要只为遵从这个PEP而打破向后兼容性！ 可以忽略部分风格指南的好理由，不要只为遵从这个PEP而打破向后兼容性！ 忽视既定指南的一些其他的好理由： 当应用指南会降低代码的可读性，即使对于那些习惯遵照这个PEP来阅读代码的人来说。 与周围的代码保持一致也会破坏它（可能是历史原因）——虽然这也是收拾别人烂摊子的好机会（在真正的XP风格中）。 因为问题代码先于指南，又没有其它的修改理由。 代码需要兼容老版本，本风格指南不建议使用的Python特性。 代码布局 缩进 每级缩进用4个空格 连续行的折叠元素应该对齐 # 与起始定界符对齐： 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) # 悬挂不一定要4个空格 foo = long_function_name( var_one, var_two, var_three, var_four) if语句条件块太长需要写成多行. 值得注意的是两个字符组成的关键字（例如if），加上一个空格，加上开括号，为后面的多行条件创建了一个4个空格的缩进。这会给嵌入if内的缩进语句产生视觉冲突，因为它们也被缩进4个空格。 这个PEP没有明确如何（是否）进一步区分条件行和if语句内的行。这种情况下，可以接受的选项包括，但不仅限于： # 不增加额外的缩进 if (this_is_one_thing and that_is_another_thing): do_something() # 添加一行注释，这将为支持语法高亮的编辑器提供一些区分 if (this_is_one_thing and that_is_another_thing): # 当两个条件都是真，我们将要执行 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, ) 制表符还是空格 空格是最优先的缩进方式 当已经使用制表符是，应该保持一致性，继续使用制表符 Python 3不允许混合使用制表符和空格来缩进。 Python 2的代码中混合使用制表符和空格的缩进，应该转化为完全使用空格