您好,欢迎访问三七文档
当前位置:首页 > 临时分类 > Python 代码风格指南
Python代码风格指南介绍本文档所提供的编码规范,适用于主要的Python发行版中组成标准库的Python代码。请参阅PEP关于Python的C实现的C编码风格指南的描述。本文档和PEP257(文档字符串规范)改编自Guido的《PythonStyleGuide》一文,并从《Barry'sstyleguide》添加了部分内容作为补充。这篇风格指南随着时间的推移而逐渐演变,随着语言本身的变化,一些过去的约定已经过时,并确定了更多新的约定。许多项目都有自己的编码风格指南。如果有任何冲突,优先使用该项目特定的指南。愚蠢地坚持一致性是无知的妖怪Guido的一个重要的见解是,代码阅读的次数比编写的次数多。这里提供的指南旨在提高代码的可读性,并使各种不同的Python代码一致。如PEP20所说,“易读性非常重要”。风格指南是关于一致性的。与本风格指南一致很重要。项目中的一致性更重要。一个模块或功能中的一致性最重要。最重要的是:知道何时会不一致——有时风格指南就不适用了。怀疑时,作出你最佳的判断。看看其他的例子,并决定什么是最好的。不要犹豫,尽管发问!特别地:不要只为遵从这个PEP而打破向后兼容性!可以忽略部分风格指南的好理由,不要只为遵从这个PEP而打破向后兼容性!忽视既定指南的一些其他的好理由:1当应用指南会降低代码的可读性,即使对于那些习惯遵照这个PEP来阅读代码的人来说。2与周围的代码保持一致也会破坏它(可能是历史原因)——虽然这也是收拾别人烂摊子的好机会(在真正的XP风格中)。3因为问题代码先于指南,又没有其它的修改理由。4代码需要兼容老版本,本风格指南不建议使用的Python特性。代码布局缩进每级缩进用4个空格连续行的折叠元素应该对齐#与起始定界符对齐:foo=long_function_name(var_one,var_two,var_three,var_four)#使用更多的缩进,以区别于其他代码deflong_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_thingandthat_is_another_thing):do_something()#添加一行注释,这将为支持语法高亮的编辑器提供一些区分if(this_is_one_thingandthat_is_another_thing):#当两个条件都是真,我们将要执行do_something()#在换行的条件语句前,增加额外的缩进if(this_is_one_thingandthat_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',)制表符还是空格空格是最优先的缩进方式当已经使用制表符是,应该保持一致性,继续使用制表符Python3不允许混合使用制表符和空格来缩进。Python2的代码中混合使用制表符和空格的缩进,应该转化为完全使用空格。调用python命令行解释器时使用-t选项,可对代码中不合法得混合制表符和空格发出警告(warnings)。使用-tt时警告(warnings)将变成错误(errors).这些选项是被高度推荐的.最大行长度限制所有行最多79个字符。下垂的长块结构限制为更少的文本(文档字符串或注释),行的长度应该限制在72个字符。限制编辑器窗口宽度使得并排打开多个文件成为可能,并且使用代码审查工具显示相邻列的两个版本工作正常。绝大多数工具的默认折叠会破坏代码的可视化结构,使其更难以理解。编辑器中的窗口宽度设置为80个字符。即使该工具将在最后一列中标记字形。一些基于网络的工具可能不会提供动态的自动换行。有些团队强烈喜欢较长的行长度。对于代码维护完全或主要由一个团队的,可以在这个问题上达成协议,象征性的将行长度从80个字符增加到100个字符(有效地增加最大长度到99个字符)也是可以的,提供注释和文档字符串仍是72个字符。Python标准库采取保守做法,要求行限制到79个字符(文档字符串/注释到72个字符)。折叠长行的首选方法是使用Pyhon支持的圆括号,方括号(brackets)和花括号(braces)内的行延续。长行可以在表达式外面使用小括号来变成多行。连续行使用反斜杠更好。反斜杠有时可能仍然是合适的。例如,长的多行的with语句不能用隐式续行,可以用反斜杠:#反斜杠有时可能仍然是合适的。例如,长的多行的with语句不能用隐式续行,可以用反斜杠:withopen('/path/to/some/file/you/want/to/read')asfile_1,\open('/path/to/some/file/being/written','w')asfile_2:file_2.write(file_1.read())另一种类似的情况是在assert语句中确认恰当地缩进了延续的行换行应该在二元操作符前面还是后面几十年来推荐的风格是在二元操作符后换行。但这会通过两种方式影响可读性:操作符往往分散在屏幕的不同的列上,并且每个操作符都被移动到远离其操作数。在这里,眼睛要做额外的工作看清哪些数是添加或减去:#坏的:操作符远离它们的操作数income=(gross_wages+taxable_interest+(dividends-qualified_dividends)-ira_deduction-student_loan_interest)为了解决这个可读性问题,数学家和出版商遵循相反的约定。DonaldKnuth在他的《电脑和排版》系列中解释了传统规则:“尽管后一段总是打破内公式二进制操作和关系,显示公式总是在二进制操作前换行”。以下的数学运算传统通常可以使得结果更加具有可读性#好的:易于匹配操作数和操作符income=(gross_wages+taxable_interest+(dividends-qualified_dividends)-ira_deduction-student_loan_interest)#二元运算符首选的换行位置在操作符后面classRectangle(Blob):def__init__(self,width,height,color='black',emphasis=None,highlight=0):ifwidth==0andheight==0and\color=='red'andemphasis=='strong'or\highlight100):raiseValueError(sorry,youlose)ifwidth==0andheight==0and(color=='red'oremphasisisNone):raiseValueError(Idon'tthinkso--valuesare%s,%s%(width,height))Blob.__init__(self,width,height,color,emphasis,highlight)在Python代码中,允许打破之前或之后一个二元运算符的规则,只要与当前惯例是一致的。为新代码Knuth的风格。空行用两行空行分割顶层函数和类的定义.类内方法的定义用单个空行分割.额外的空行可被用于(保守的(sparingly))分割一组相关函数(groupsofrelatedfunctions).在一组相关的单句中间可以省略空行.(例如.一组哑元(asetofdummyimplementations)).在函数中使用空行时,请谨慎的用于表示一个逻辑段落(indicatelogicalsections).Python接受contol-L(即^L)换页符作为空格;Emacs(和一些打印工具)视这个字符为页面分割符,因此在你的文件中,可以用他们来为相关片段(sections)分页。注意,一些编辑器和基于Web的代码查看器可能不能识别control-L是换页,将显示另外的字形。源文件编码Python核心发布中的代码应该始终使用UTF-8(或Python2中用ASCII)。文件使用ASCII(Python2中)或UTF-8(Python3中)不应有编码声明。在标准库中,非默认编码仅用于测试目的或注释或文档字符串需要提及包含非ASCII字符的作者名;否则,使用\x,\u,\U,或\N是字符串中包含非ASCII数据的首先方式。Python3.0及以上版本,为标准库(参见PEP3131)规定以下策略:Python标准库中的所有标识符必须使用ASCII标识符,在可行的地方使用英文单词(在很多例子中,使用非英文的缩写和专业术语)。另外,字符串和注释必须用ASCII。仅有的例外是(a)测试非ASCII的特点,(b)测试作者名。不是基于拉丁字母表的作者名必须提供一个他们名字的拉丁字母表的音译。开源项目面向全球,鼓励采用统一策略。导入#通常应该在单独的行中导入(Imports)importosimportsys#这样也是可以的fromsubprocessimportPopen,PIPEImports通常被放置在文件的顶部,仅在模块注释和文档字符串之后,在模块的全局变量和常量之前.Imports应该有顺序地成组安放.•标准库的导入(Imports)•相关的第三方导入(即,所有的email包在随后导入)•特定的本地应用/库导入(imports)•你应该在每组导入之间放置一个空行.把任何相关all规范放在导入之后。推荐绝对导入,因为它们更易读,并且如果导入系统配置的不正确(例如当包中的一个目录在sys.path的最后)它们有更好的表现(或者至少给出更好的错误信息):importmypkg.siblingfrommypkgimportsiblingfrommypkg.siblingimportexample明确的相对导入可以被接受用来替代绝对导入,特别是处理复杂的包布局时,绝对导入过于冗长。from.importsiblingfrom.siblingimportexample标准库代码应该避免复杂包布局并使用绝对导入。隐式的相对导入应该永远不被使用,并且在Python3中已经移除。从一个包含类的模块中导入类时,下面这样通常是好的写法:frommyclassimportMyClassfromfoo.bar.yourclassimportYourClass#如果这种写法导致本地名字冲突,那么就这样写:importmyclassimportfoo.bar.yourclass#并使用“myclass.MyClass”和“foo.bar.yourclass.YourClass”来访问。避免使用通配符导入(from模块名import*),因为这样就不清楚哪些名字出现在命名空间,这会让读者和许多自动化工具困惑。通配符导入有一种合理的使用情
本文标题:Python 代码风格指南
链接地址:https://www.777doc.com/doc-4210397 .html