Python风格指南(Google版)
注意: 本人现在已将博客都移动到个人博客,查看更多请点击此处
Python 是 Google主要的脚本语言。这本风格指南主要包含的是针对python的编程准则。使得Python代码编写更加规范、优美。
Python语言规范
Lint
对你的代码允许pylint
定义:
pylint是一个在Python源代码中查找bug的工具。对于C和C++这样的不那么动态的语言,这些bug通常由编译器来捕获。由于Python的动态特性,有些警告可能不对。不过伪告警应该很少。
优点:
可以捕获容易忽视的错误,例如输入错误、使用未赋值的变量等。
缺点:
pylint并不不完美。要利用其优势,我们有时侯需要:
- 围绕着它来写代码
- 抑制其告警
- 改进它
- 忽略它
结论:
确保对你的代码运行pylint。抑制不准确的警告,以便能够将其他警告暴露出来。
你可以通过设置一个行注释来抑制告警。
dict = 'something awful' # Bad Idea... pylint: disable=redefined-builtin
pylint警告是以一个数字编号(如C0112
)和一个符号名(如empty-docstring
)来标识的。在编写新代码或更新已有代码时对告警进行抑制,推荐使用符号名来标识。
如果警告的符号名不够见名知意,那么请对其增加一个详细解释。
采用这种抑制方式的好处是我们可以轻松查找抑制并回顾它们。
你可以使用命令pylint --list-msgs
来获取pylint告警列表. 你可以使用命令pylint --help-msg=C6409
,以获取关于特定消息的更多信息。
相比较于之前使用的pylint: disable-msg
,本文推荐使用pylint: disable
。
要抑制”参数未使用”告警,你可以用””作为参数标识符, 或者在参数名前加”unused”。遇到不能改变参数名的情况,你可以通过在函数开头”提到”它们来消除告警。例如
_ = d, ereturn a
导入
仅对包和模块使用导入
定义:
模块间共享代码的重用机制。
优点:
命名空间管理约定十分简单。每个标识符的源都用一种一致的方式指示。x.Obj表示Obj对象定义在模块X中。
缺点:
模块名仍有可能冲突。有些模块名太长,不太方便。
结论:
- 使用
import x
来导入包和模块。 - 使用
from x import y
,其中x是包前缀,y是不带前缀的模块名。 - 使用
from x import y as z
,如果两个要导入的模块都叫做y或者有太长了。from sound.effects import echo...echo - 导入时不要使用相对名称。即使模块在同一个包中,也要使用完整包名。这能帮助你避免无意间导入一个包两次。
包
使用模块的全路径名来导入每个模块。
优点:
避免模块名冲突。查找包更容易。
缺点:
部署代码变难,因为你必须复制包层次。
结论:
所用的新代码都应该用完整包名来导入每个模块。
# Reference in code with complete name.import sound.effects.echo# Reference in code with just module name (preferred).from sound.effects import echo
异常
允许使用异常,但必须小心。
定义:
异常是一种跳出代码块的正常控制流程来处理错误或者其他异常条件的方式。
优点:
正常操作代码的控制流不会和错误处理代码混在一起。当某种条件发生时,它也允许控制流跳过多个框架。例如,一步跳出N个嵌套的函数,而不必继续执行错误的代码。
缺点:
可能会导致让人困惑的控制流。调用库时容易错过错误情况。
结论:
异常必须遵守特定条件:
- 像这样触发异常:
raise MyException("Error message")
或者raise MyException
。不要使用两个参数的形式(raise MyException,"Error message"
)或者过时的字符串异常(raise "Error message")
。 - 模块或包应该定义自己的特定域的异常基类,这个基类应该从内建的Exception类继承。模块的异常基类应该叫做”Error”。
- 永远不要使用
except:
语句来捕获所有异常,也不要捕获Exception
或者StandardError
,除非你打算重新触发该异常,或者你已经在当前线程的最外层(记得还是要打印一条错误消息)。在异常这方面,Python非常宽容,except:
真的会捕获包括Python语法错误在内的任何错误。使用except:
很容易隐藏真正的bug。 - 尽量减少try/except块中的代码量。try块的体积越大,期望之外的异常就越容易被触发。这种情况下,try/except块将隐藏真正的错误。
- 使用finally子句来执行那些无论try块中有没有异常都应该被执行的代码。这对于清理资源常常很有用,例如关闭文件。
- 当捕获异常时, 使用
as
而不要用逗号。try:raise Errorexcept Error as error:pass
全局变量
避免全局变量
定义:
定义模块级的变量。
优点:
偶尔使用。
缺点:
导入时可能改变模块行为,因为导入模块时会对模块级变量赋值。
结论:
避免使用全局变量,用类变量来代替。但有一些例外:
- 脚本的默认选项。
- 模块级常量。
- 有时候用全局变量来缓存值或者作为函数返回值很有用。
- 如果需要,全局变量应该仅在模块内部作用,并通过模块级的公共函数来访问。
嵌套、局部、内部类或函数
鼓励使用嵌套、本地、内部类或函数
定义:
类可以定在方法、函数或者类中。函数可以定义在方法或函数中,封闭区间中定义的变量对嵌套函数是只读的。
优点:
允许定义仅用于有效函数的工具类和函数。
缺点:
嵌套类或局部类的实例不能序列化(picked)。
结论:
推荐使用。
列表推导(List Comprehensions)
可以在简单情况下使用。
定义:
列表推导(list comprehensions)与生成器表达式(generator expression)提供了一种简洁高效的方式来创建列表和迭代器,而不必借助map(),filter(),或者lambda。
优点:
简单的列表推导可以比其它的列表创建方法更加清晰简单。生成器表达式可以十分高效,因为它们避免了创建整个列表。
缺点:
复杂的列表推导或者生成器表达式可能难以阅读。
结论:
适用于简单情况。每个部分应该单独置于一行: 映射表达式,for语句,过滤器表达式。禁止多重for语句或过滤器表达式。复杂情况下还是使用循环。
result =for x in :for y in :if x * y > 10:resultfor x in :for y in :if x != y:for z in :if y != z:yield (x, y, z)return ((x, )for x inif x is not None)squares =
默认迭代器和操作符
如果类型支持,就使用默认迭代器和操作符.比如列表、字典及文件等。
定义:
容器类型,像字典和列表,定义了默认的迭代器和关系测试操作符(in和not in)。
优点:
默认操作符和迭代器简单高效,它们直接表达了操作,没有额外的方法调用。使用默认操作符的函数是通用的。它可以用于支持该操作的任何类型。
缺点:
没法通过阅读方法名来区分对象的类型(例如has_key()意味着字典)。不过这也是优点。
结论:
如果类型支持,就使用默认迭代器和操作符,例如列表、字典和文件。内建类型也定义了迭代器方法。优先考虑这些方法,而不是那些返回列表的方法。当然,这样遍历容器时,你将不能修改容器。
for key in adict: ...if key not in adict: ...if obj in alist: ...for line in afile: ...for k, v in dict : ...
生成器
按需使用生成器.
定义:
所谓生成器函数,就是每当它执行一次生成(yield)语句,它就返回一个迭代器,这个迭代器生成一个值。生成值后,生成器函数的运行状态将被挂起,直到下一次生成。
优点:
简化代码,因为每次调用时,局部变量和控制流的状态都会被保存。比起一次创建一系列值的函数, 生成器使用的内存更少。
缺点:
没有。
结论:
鼓励使用。注意在生成器函数的文档字符串中使用”Yields:”而不是”Returns:”。
Lambda表达式
适用于单行函数
定义:
与语句相反,lambda在一个表达式中定义匿名函数。常用于为map()
和filter()
之类的高阶函数定义回调函数或者操作符。
优点:
方便。
缺点:
比本地函数更难阅读和调试。没有函数名意味着堆栈跟踪更难理解。由于lambda函数通常只包含一个表达式,因此其表达能力有限。
结论:
适用于单行函数。如果代码超过60-80个字符,最好还是定义成常规(嵌套)函数。
对于常见的操作符,例如乘法操作符,使用operator
模块中的函数以代替lambda函数. 例如, 推荐使用operator.mul
, 而不是lambda x, y: x * y
.
条件表达式
适用于单行函数。
定义:
条件表达式是对于if语句的一种更为简短的句法规则。例如:x = 1 if cond else 2
。
优点:
比if语句更加简短和方便。
缺点:
比if语句难于阅读。如果表达式很长,难于定位条件。
结论:
适用于单行函数。在其他情况下,推荐使用完整的if语句。
默认参数值
适用于大部分情况。
定义:
你可以在函数参数列表的最后指定变量的值,例如def foo(a, b = 0):。如果调用foo时只带一个参数,则b被设为0。如果带两个参数,则b的值等于第二个参数。
优点:
你经常会碰到一些使用大量默认值的函数,但偶尔(比较少见)你想要覆盖这些默认值。默认参数值提供了一种简单的方法来完成这件事,你不需要为这些罕见的例外定义大量函数。同时,Python也不支持重载方法和函数,默认参数是一种”仿造”重载行为的简单方式。
缺点:
默认参数只在模块加载时求值一次。如果参数是列表或字典之类的可变类型,这可能会导致问题。如果函数修改了对象(例如向列表追加项),默认值就被修改了。
结论:
鼓励使用。不过有如下注意事项:
不要在函数或方法定义中使用可变对象作为默认值。
if b is None:
b =
属性(properties)
访问和设置数据成员时,你通常会使用简单,轻量级的访问和设置函数。建议用属性(properties)来代替它们。
定义:
一种用于包装方法调用的方式。当运算量不大,它是获取和设置属性(attribute)的标准方式。
优点:
通过消除简单的属性(attribute)访问时显式的get和set方法调用,可读性提高了。允许懒惰的计算。用Pythonic的方式来维护类的接口。就性能而言,当直接访问变量是合理的,添加访问方法就显得琐碎而无意义。使用属性(properties)可以绕过这个问题。将来也可以在不破坏接口的情况下将访问方法加上。
缺点:
属性(properties)是在get和set方法声明后指定,这需要使用者在接下来的代码中注意:set和get是用于属性(properties)的(除了用property
装饰器创建的只读属性)。必须继承自object类。可能隐藏比如操作符重载之类的副作用.。继承时可能会让人困惑。
结论:
你通常习惯于使用访问或设置方法来访问或设置数据,它们简单而轻量。不过我们建议你在新的代码中使用属性。只读属性应该用property
装饰器来创建。
如果子类没有覆盖属性,那么属性的继承可能看上去不明显。因此使用者必须确保访问方法间接被调用,以保证子类中的重载方法被属性调用(使用模板方法设计模式)。
Ture、False的求值
尽可能使用隐式false。
定义:
Python在布尔上下文中会将某些值求值为false。按简单的直觉来讲,就是所有的”空”值都被认为是false。因此0,None,[],{},“” 都被认为是false。
优点:
使用Python布尔值的条件语句更易读也更不易犯错。大部分情况下,也更快。
缺点:
对C/C++开发人员来说。可能看起来有点怪。
结论:
尽可能使用隐式的false,例如:使用if foo:
而不是if foo != []:
。不过还是有一些注意事项需要你铭记在心:
永远不要用==或者!=来比较单件,比如None。使用is或者is not。
当你写下
if x:
时,你其实表示的是if x is not None
。例如:当你要测试一个默认值是None的变量或参数是否被设为其它值。这个值在布尔语义下可能是false!永远不要用==将一个布尔量与false相比较。使用
if not x:
代替。如果你需要区分false和None,你应该用像if not x and x is not None:
这样的语句。对于序列(字符串、列表、元组),要注意空序列是false。因此
if not seq:
或者if seq:
比if len(seq):
或if not len(seq):
要更好。处理整数时,使用隐式false可能会得不偿失(即不小心将None当做0来处理)。你可以将一个已知是整型(且不是len()的返回结果)的值与0比较。
注意‘0’(字符串)会被当做true。
过时的语言特性
尽可能使用字符串方法取代字符串模块。使用函数调用语法取代apply()。使用列表推导,for循环取代filter(),map()以及reduce()。
定义:
当前版本的Python提供了大家通常更喜欢的替代品。
结论:
我们不使用不支持这些特性的Python版本,所以没理由不用新的方式。
此法作用域(Lexical Scoping)
推荐使用。
定义:
嵌套的Python函数可以引用外层函数中定义的变量,但是不能够对它们赋值。变量绑定的解析是使用词法作用域,也就是基于静态的程序文本。对一个块中的某个名称的任何赋值都会导致Python将对该名称的全部引用当做局部变量,甚至是赋值前的处理。如果碰到global声明,该名称就会被视作全局变量。
优点:
通常可以带来更加清晰,优雅的代码。尤其会让有经验的Lisp和Scheme(还有Haskell、ML等)程序员感到欣慰。
缺点:
可能导致让人迷惑的bug。
结论:
鼓励使用。
函数与方法装饰器
如果好处很显然, 就明智而谨慎的使用装饰器
定义:
用于函数及方法的装饰器(也就是@标记)。最常见的装饰器是@classmethod 和@staticmethod,用于将常规函数转换成类方法或静态方法。不过,装饰器语法也允许用户自定义装饰器。特别地,对于某个函数my_decorator
,下面的两段代码是等效的:
# method body ...
# method body ...method =
优点:
优雅的在函数上指定一些转换。该转换可能减少一些重复代码,保持已有函数不变(enforce invariants)等.
缺点:
装饰器可以在函数的参数或返回值上执行任何操作,这可能导致让人惊异的隐藏行为。而且,装饰器在导入时执行。从装饰器代码的失败中恢复更加不可能。
结论:
如果好处很显然,就明智而谨慎的使用装饰器。装饰器应该遵守和函数一样的导入和命名规则。装饰器的python文档应该清晰的说明该函数是一个装饰器。请为装饰器编写单元测试。
避免装饰器自身对外界的依赖(即不要依赖于文件、socket、数据库连接等),因为装饰器运行时这些资源可能不可用(由pydoc或其它工具导入)。应该保证一个用有效参数调用的装饰器在所有情况下都是成功的。
装饰器是一种特殊形式的”顶级代码”。
线程
不要依赖内建类型的原子性。
虽然Python的内建类型例如字典看上去拥有原子操作,但是在某些情形下它们仍然不是原子的(即: 如果hash或eq被实现为Python方法)且它们的原子性是靠不住的。你也不能指望原子变量赋值(因为这个反过来依赖字典)。
优先使用Queue模块的Queue
数据类型作为线程间的数据通信方式.。另外,使用threading模块及其锁原语(locking primitives)。了解条件变量的合适使用方式,这样你就可以使用threading.Condition
来取代低级别的锁了。
威力过大的特性
避免使用这些特性。
定义:
Python是一种异常灵活的语言,它为你提供了很多花哨的特性,诸如元类(metaclasses),字节码访问,任意编译(on-the-fly compilation),动态继承,对象父类重定义(object reparenting),导入黑客(import hacks),反射、系统内修改(modification of system internals)等等。
优点:
强大的语言特性,能让你的代码更紧凑。
缺点:
使用这些很”酷”的特性十分诱人,但不是绝对必要。使用奇技淫巧的代码将更加难以阅读和调试。开始可能还好(对原作者而言),但当你回顾代码,它们可能会比那些稍长一点但是很直接的代码更加难以理解。
结论:
在你的代码中避免这些特性。
标准的模版库和类在内部使用这些功能都还可以使用(列如:abc.ABCMeta
、collections.namedtuple
和enum
)。
现代Python:Python 3和from__future__import{#modern-python}
Python3的时代。虽然不是每个项目都准备好但使用它,但是所有的代码应该面向未来的眼光来写。
定义:
Python 3 是一个很重要的改变在Python语言中,虽然现有的代码通常是以2.7的形式编写的,但为了使代码更明确地表达其意图,需要做一些简单的事情,从而更好地准备好在Python 3下使用而无需进行修改。
优点:
使用Python 3编写的代码在您的项目的所有依赖项都准备就绪后,会更加明确,并且更容易在Python 3下运行。
缺点:
有些人觉得额外的样例很丑。 其他人说,“但我不在这个文件中使用该功能”,并希望清理。 请不要。 在所有文件中始终保留未来的导入效果会更好,以便在稍后进行编辑时,在有人开始使用此功能时不会忘记它们。
结论:
from__future__import
鼓励使用from future import语句。所有新代码应包含以下内容,并且应尽可能更新现有代码以使其兼容:
from __future__ import absolute_importfrom __future__ import divisionfrom __future__ import print_function
还有其他from__future__
语句。 如果您认为合适,请使用它们。 我们不建议使用unicode_literals
,因为它在Python 2.7中的许多地方引入了隐式默认编解码器转换后果,因此它不是一个明显的胜利。 大多数代码在显式使用b''
和u''
字节和必要的unicode字符串文字时效果更好。
The six、future or past libraries.
当项目需要在Python 2和Python 3下积极支持使用时,在合适的情况下,鼓励使用这些库。 它们的存在是为了让您的代码更简洁,更轻松。
类型标注的代码
你可以通过PEP-484标准注释Python 3的类型提示,并且在构建时使用类型检查工具(比如pytype)检查代码。
类型注释可以在源代码或stub pyi file中。 只要有可能,注释应该在源代码中。 为第三方或扩展模块使用pyi文件。
定义:
类型注释(或者“类型提示”)用于函数或方法参数和返回值:
你还可以使用特殊注释声明变量的类型:
a = # type: SomeType
优点:
类型注释提高了代码的可读性和可维护性。类型检查器会将许多运行时错误转换为构建时错误,并降低你使用强大特性的能力。
缺点:
你将不得不保持类型声明是最新的。你有可能会看到你认为是有效代码的类型错误的。用代码检查器可以降低你使用强大特性的的能力。
结论:
这很大程度上取决于您项目的复杂程度。 试一试。
Python风格规范
分号
不要在行尾加分号,也不要用分号将两条命令放在同一行。
行长度
每行长度不超过80字符。包括长的导入模块语句、注释里的URL等。 不要使用反斜杆连接行。Python会将圆括号、中括号和花括号中的行隐式连接起来
,可以利用这个特点,如果需要连接可以在表达式外围增加一对额外的圆括号。 注:如果有必要,将长的URL可以放在一行。
括号
宁缺毋滥的使用括号。
除非是在使用实现行连接,否则不要在返回语句或条件语句中使用括号。不过在元组两边是可以的。
缩进
用四个空格来缩进代码。
绝对不要用Tab,也不要用tab和空格混用。对于行连接的情况,要么垂直对其换行的元素,或者使用4空格的悬挂式缩进。
空行
顶级定义之间空两行,方法定义之间空一行。
顶级定义之间空两行,比如函数或者类定义。方法定义,类定义与第一个方法之间,都应该空一行. 函数或方法中,某些地方要是你觉得合适,就空一行。
空格
按照标准的排版规范来使用标点两边的空格。
- 括号内不要使用空格。
- 不要在逗号、分号、冒号前面加空格,但应该在它们后面加(除了行尾)。
- 参数列表、索引或切片的做括号前不应该加空格。
- 在二元操作符两边都应该加上一个空格,至于算术操作符两边的空格该如何使用,需要你自己好好判断。不过两侧务必要保持一致。
- 当'='用于指示关键字或参数默认值时,不要在其两侧使用空格。
- 不要用空格来处置对齐多行简的标记。
Shebang
大部分.py文件不必以#!作为文件的开始。但是程序的main文件应该以 #!/usr/bin/python2或者#!/usr/bin/python3开始。
注释
确保对模块、函数,方法和行内注释使用正确的风格。
文档字符串
Python有一种独一无二的注释方式:使用文档字符串。文档字符串是包、模块,类或函数的一个语句。这些字符串可以通过对象的__doc__
成员被自动提取,并用被pydoc所用。对文档字符串的惯例是使用三重双引号"""。 一个文档字符串应该这样组织:
- 首先是一行以问号、句号和感叹号结尾的概述。
- 接着是一个空行。
- 接着是文档字符串剩下的部分,它应该与文档字符串的第一行的第一个引号对齐。
模块
每个文件应该包含一个许可样板,根据项目使用许可(例如:Apache 2.0、BSD、LGPL、GPL),选择合适的样板。
函数和方法
下文所指的函数包括函数、方法以及生成器。
一个函数必须要有文档字符串,除非它满足以下条件:
- 外部不可见
- 非常短小
- 简单明了 文档字符串应该包含函数做什么,以及输入和输出的详细描述。通常,不应该描述“怎么做”,除非是一些复杂的算法,文档字符串应该提供足够的信息,当别人编写代码调用该函数时,他不需要看一行代码,只要看文档字符串就可以了,对于复杂的代码,在代码旁边加注释会比使用文档字符串更有意义。
关于函数的几个方面应该在特定的小节中进行描述记录,这几个方面如下文所述。每节应该以一个标题行开始。标题行以冒号结尾。除标题行外、节的其他内容应被缩进2个空格。
Args: 列出每个参数的名字,并在名字后使用一个冒号和一个空格,分隔对该参数的描述。如果描述太长超过了单行80字符,使用2或者4个空格的悬挂缩进(与文件其他部分保持一致)。描述应该包括所需的类型和含义。如果一个函数接受foo(可变长度参数列表)或者**bar(任意关键字参数),应该详细列出foo和bar。 Returns(或者Yield:用于生成器): 描述返回值的类型和语义。如果函数返回None,这一部分可以省略。 Raises:** 列出与接口有关的所有异常。
"""Fetches rows from a Bigtable.Retrieves rows pertaining to the given keys from the Table instancerepresented by big_table. Silly things may happen ifother_silly_variable is not None.Args:big_table: An open Bigtable Table instance.keys: A sequence of strings representing the key of each table rowto fetch.other_silly_variable: Another optional variable,that has a muchlonger name than the other args,and which does nothing.Returns:A dict mapping keys to the corresponding table row datafetched. Each row is represented as a tuple of strings. Forexample:{'Serak': ('Rigel VII','Preparer'),'Zim': ('Irk','Invader'),'Lrrr': ('Omicron Persei 8','Emperor')}If a key from the keys argument is missing from the dictionary,then that row was not found in the table.Raises:IOError: An error occurred accessing the bigtable.Table object."""pass
类
类应该在其定义下有一个用于描述该类的文档字符串。如果你的类有公共属性(Attributes),那么文档中应该有一个属性(Attributes)段。并且应该遵守和函数参数相同的格式。
"""Summary of class here.
Longer class information....
Longer class information....
Attributes:
likes_spam: A boolean indicating if we like SPAM or not.
eggs: An integer count of the eggs we have laid.
"""
"""Inits SampleClass with blah."""
self.likes_spam = likes_spam
self.eggs = 0
"""Performs operation blah."""
块注释和行注释
最需要写注释的是代码中那些技巧性的部分。如果你在下次代码审查
的时候必须解释一下,那么你应该现在就给它写注释。对于复杂的操作,应该在其操作开始前写上若干行注释。对于不是一目了然的代码,应在其行尾添加注释。
# We use a weighted dictionary search to find out where i is in
# the array. We extrapolate position based on the largest num
# in the array and the array size and then do binary search to
# get the exact number.
if i & (i-1) == 0: # true iff i is a power of 2
- 为了提高可读性,注释应该至少离开代码2个空格。
- 另一方面,绝不要描述代码。假设阅读代码的人比你更懂Python,他只是不知道你的代码要做什么。
# BAD COMMENT: Now go through the b array and make sure whenever i occurs
# the next element is i+1
类
如果一个类不继承自其它类,就显式的从object继承,嵌套类也一样。
passpass"""Explicitly inherits from another class already."""
继承自object
是为了使属性(properties)正常工作并且这样可以保护你的代码,使其不受PEP-3000的一个特殊的潜在不兼容性影响。这样做也定义了一些特殊的方法,这些方法实现了对象的默认语义。包括__new__,__init__, __delattr__,__getattribute__,__setattr__,__hash__,__repr__and __str__
字符串
即使参数都是字符串,使用%操作符或者格式化方法格式化字符串。不过也不能一概而论,你需要在+和%之间好好判定。
x = a + b
x = '%s,%s!' % (imperative,expletive)
x = '{},{}!'
x = 'name: %s; score: %d' % (name,n)
x = 'name: {}; score: {}'
避免在循环中用+和+=操作符来累加字符串。由于字符串是不可变的,这样做会创建不必要的临时对象,并且导致二次方而不是线性的运行时间。作为替代方案,你可以将每个子串加入列表,然后在循环结束后用.join
连接列表。(也可以将每个子串写入一个 .cStringIO.StringIO
缓存中。)
items =
for last_name,first_name in employee_list:
items
items
employee_table = '
在同一个文件中,保持使用字符串引号的一致性。使用单引号'或者双引号"之一用以引用字符串,并在同一文件中沿用。在字符串内可以使用另外一种引号,以避免在字符串中使用。PyLint已经加入了这一检查。
为多行字符串使用三重双引号"""而非三重单引号'''。当且仅当项目中使用单引号'来引用字符串时,,才可能会使用三重'''为非文档字符串的多行字符串来标识引用。文档字符串必须使用三重双引号"""。不过要注意,通常用隐式行连接更清晰,因为多行字符串与程序其他部分的缩进方式不一致。
print ("This is much nicer.\n"
"Do it this way.\n")
文件和sockets
在文件和sockets结束时,显式的关闭它。
除文件外,sockets或其他类似文件的对象在没有必要的情况下打开,会有许多副作用,例如:
- 它们可能会消耗有限的系统资源,如文件描述符。如果这些资源在使用后没有及时归还系统,那么用于处理这些对象的代码会将资源消耗殆尽。
- 持有文件将会阻止对于文件的其他诸如移动、删除之类的操作。
- 仅仅是从逻辑上关闭文件和sockets,那么它们仍然可能会被其共享的程序在无意中进行读或者写操作。只有当它们真正被关闭后,对于它们尝试进行读或者写操作将会抛出异常,并使得问题快速显现出来。
而且,幻想当文件对象析构时,文件和sockets会自动关闭,试图将文件对象的生命周期和文件的状态绑定在一起的想法,都是不现实的。因为有如下原因:
- 没有任何方法可以确保运行环境会真正的执行文件的析构。不同的Python实现采用不同的内存管理技术,如延时垃圾处理机制。延时垃圾处理机制可能会导致对象生命周期被任意无限制的延长。
- 对于文件意外的引用,会导致对于文件的持有时间超出预期(比如对于异常的跟踪,包含有全局变量等)。 推荐使用
"with"语句
以管理文件:
对于不支持使用"with"语句的类似文件的对象,使用with as hello_file:for line in hello_file:print linecontextlib.closing()
: ```python import contextlib
with contextlib.closing(urllib.urlopen("http://www.python.org/")) as front_page: for line in front_page: print line
#### TODO注释为临时代码使用TODO注释,它是一种短期解决方案。不算完美,但够好了。TODO注释应该在所有开头处包含”TODO”字符串,紧跟着是用括号括起来的你的名字,email地址或其它标识符。然后是一个可选的冒号,接着必须有一行注释,解释要做什么。主要目的是为了有一个统一的TODO格式。这样添加注释的人就可以搜索到(并可以按需提供更多细节)。写了TODO注释并不保证写的人会亲自解决问题。当你写了一个TODO,请注上你的名字。```python# TODO(xujavy@gmail.com): Use a "*" here for string repetition.# TODO(Javy) Change this to use relations.
如果你的TODO是"将来做某事"的形式,那么请确保你包含了一个指定的日期("2018年3月解决")或者一个特定的事件("等到所有的客户都可以处理XML请求就移除这些代码")。
#### 导入格式每个导入应该独占一行。```pythonimport osimport sys
导入总应该放在文件顶部,位于模块注释和文档字符串之后,模块全局变量和常量之前。导入应该按照从最通用到最不通用的顺序分组:
- 标准库导入
- 第三方库导入
- 应用程序指定导入 每种分组中,应该根据每个模块的完整包路径按字典序排序,忽略大小写。import foofrom foo import barfrom foo.bar import bazfrom foo.bar import Quuxfrom Foob import ar
语句
通常每个语句应该独占一行。
不过,如果测试结果与测试语句在一行放得下,你也可以将它们放在同一行。如果是if语句,只有在没有else时才能这样做。特别地,绝不要对y/except这样做,因为try和except不能放在同一行。
访问控制
在Python中,对于琐碎又不太重要的访问函数,你应该直接使用公有变量来取代它们,这样可以避免额外的函数调用开销。当添加更多功能时,你可以用属性(property)来保持语法的一致性。
另一方面,如果访问更复杂,或者变量的访问开销很显著,那么你应该使用像get_foo()
和set_foo()
这样的函数调用。如果之前的代码行为允许通过属性(property)访问,那么就不要将新的访问函数与属性绑定。这样,任何试图通过老方法访问变量的代码就没法运行,使用者也就会意识到复杂性发生了变化。
命名
module_name,package_name,ClassName,method_name,ExceptionName,function_name,GLOBAL_VAR_NAME,instance_var_name,function_parameter_name,local_var_name。
应该避免的名字
- 单字符名称, 除了计数器和迭代器。
- 包/模块名中的连字符(-)。
- 双下划线开头并结尾的名称(Python保留,例如init)。
命名约定
- 所谓"内部(Internal)"表示仅模块内可用,或者在类内是保护或私有的。
- 用单下划线(_)开头表示模块变量或函数是protected的(使用import * from时不会包含)。
- 用双下划线(__)开头的实例变量或方法表示类内私有。
- 将相关的类和顶级函数放在同一个模块里。不像Java,没必要限制一个类一个模块。
- 对类名使用大写字母开头的单词(如CapWords, 即Pascal风格),但是模块名应该用小写加下划线的方式(如lower_with_under.py)。尽管已经有很多现存的模块使用类似于CapWords.py这样的命名,但现在已经不鼓励这样做,因为如果模块名碰巧和类名一致,这会让人困扰。
Python之父Guido推荐的规范
Type | Public | Internal |
---|---|---|
Modules | lower_with_under | _lower_with_under |
Packages | lower_with_under | |
Classes | CapWords | _CapWords |
Exceptions | CapWords | |
Functions | lower_with_under() | _lower_with_under() |
Global/Class Constants | CAPS_WITH_UNDER | _CAPS_WITH_UNDER |
Global/Class Variables | lower_with_under | _lower_with_under |
Instance Variables | lower_with_under | _lower_with_under (protected) or __lower_with_under (private) |
Method Names | lower_with_under() | _lower_with_under() (protected) or __lower_with_under() (private) |
Function/Method | Parameters | lower_with_under |
Local Variables | lower_with_under |
Main
即使是一个打算被用作脚本的文件,也应该是可导入的。并且简单的导入不应该导致这个脚本的主功能(main functionality)被执行,这是一种副作用。主功能应该放在一个main()函数中。
在Python中,pydoc以及单元测试要求模块必须是可导入的。你的代码应该在执行主程序前总是检查if __name__ == '__main__'
,这样当模块被导入时主程序就不会被执行。
...
if __name__ == '__main__':
所有的顶级代码在模块导入时都会被执行。要小心不要去调用函数,创建对象,或者执行那些不应该在使用pydoc时执行的操作。
函数长度
喜欢小而专注的函数。
我们知道长函数有时是合适的,所以对函数长度没有硬性限制。 如果功能超过40行,请考虑是否可以在不影响程序结构的情况下将其分解。
即使长函数依然可以正常工作,但有人在几个月内修改它可能会增加新的行为。这可能会导致很难找到的错误。保持你函数的简短,使其他人更容易阅读和修改你的代码。
使用某些代码时,可能会发现长而复杂的函数。不要被修改现有代码而吓倒:如果使用这样的函数证明是困难的,你会发现错误是很难调试发现的,或者你想在几个不同的上下文中使用它的一部分,考虑把函数分解成更小的、更易于管理的函数。
类型注释
普通规则
- 熟悉PEP-484.
- 在方法中,永远不要注释self或cls。
- 如果不应表达任何其他变量或返回类型,请使用Any。
- 你不需要注释模块中的所有功能。
- 至少注释你的公共API。
- 使用判断力一方面可以在安全性和清晰度之间取得良好的平衡,另一方面可以灵活应对。
- 注释容易出现类型相关错误的代码(以前的错误或复杂性)。
- 注释难以理解的代码。
- 注释代码从类型角度来看变得稳定。在很多情况下,你可以在成熟代码中注释所有功能,而不会失去太多的灵活性。
断行
尝试遵循现有的缩进规则。 总是喜欢在各种变量之间断开。
注释后,许多功能将成为“每行一个参数”。
...
但是,如果所有东西都放在一行,那也是合适的。
...
如果函数名称,最后一个参数和返回类型的组合太长,则在新行中缩进4。
def my_method(self, first_var: int) -> Tuple[MyLongType1, MyLongType1]:
当返回类型与最后一个参数不在同一行时,首选方法是将参数缩进4行,并将右括号与def对齐。
...
pylint
允许你将右括号移动到一个新的行并与开头的对齐,但这是可读较差,如下所示。
...
正如在上面的例子中,不要打破类型。但是,有时它们太长而无法在一行上(尽量保持子类型不间断)。
...
如果单个名称和类型太长,请考虑为该类型使用别名。最后的手段是断开冒号和缩进四行。
前置声明
如果需要使用尚未定义的相同模块中的类名-例如,如果需要类声明中的类,或者使用了下面定义的类 - 请为该类使用字符串名称。
默认值
根据PEP-008将参数注释与默认值相结合,在=号周围使用空格(但仅限于那些同时具有注释和默认值的参数)。
...
NoneType
在Python类型系统中,NoneType
是“第一类”类型,出于输入的目的,None
是NoneType
的别名。如果参数可以是None,则必须声明!你可以使用Union
,但如果只有一个其他类型,则Optional
是一个快捷方式。
...
如果参数的默认值为None
,则标记变量Optional
是可选的。
...
...
类型别名
你可以为复杂类型声明别名。别名的名称应该是CapWorded
; 尝试描述组合类型并以“Type”(或返回元组的“类型”)结束。如果该别名仅在本模块中使用,则应该是_Private。
例如,如果模块名称与类型一起太长: SomeType = module_with_long_name.TypeWithLongName
其他例子是复杂的嵌套类型和函数的多个返回变量(作为元组)。
忽略类型
你可以使用特殊注释#type:ignore
禁用类型检查。
pytype
对特定的错误有一个禁用选项(类似于lint):
# pytype: disable=attribute-error
键入内部变量
如果内部变量的类型很难或不可能推断,那么可以将其作为特殊评论提供: a = SomeUndecoratedFunction() # type: Foo
元组和列表
与仅有单一类型的列表不同,元组可以具有单个重复类型或具有不同类型的一定数量的元素。后者通常用作函数的返回类型。
a = # type: List[int]
b = (1, 2, 3) # type: Tuple[int, ...]
c = (1, "2", 3.5) # type Tuple[int, str, float]
TypeVar
Python类型系统具有generics。 工厂函数TypeVar是使用它们的常用方法。 例如:
from typing import List, TypeVar
T =
...
return l
TypeVar可以被约束:
AddableType =return a + b
类型
变量中一个常见的预定义类型变量是AnyStr
。 将它用于可以是bytes
或unicode
的参数。
AnyStr =
字符串类型
当注释接收或返回字符串的函数时,避免使用str
,因为它在Python 2和Python 3中意味着不同的东西。在Python 2中,str
是bytes
; 在Python 3中,它是unicode
。 只要有可能,最好是明确的.
对于处理字节数组的代码,请使用bytes
。
...
对于处理Unicode数据的代码,请使用Text
。
from typing import Text
...
...
如果类型可以是字节或unicode,则使用Union
。
from typing import Text, Union
...
...
如果函数的所有字符串类型始终相同,例如,如果返回类型与上面代码中的参数类型相同,请使用AnyStr。
以这种方式编写代码将简化将代码移植到Python 3的过程。
类型导入
对于来自typing
模块的类,始终导入类本身。明确允许从typing
模块的一行中导入多个特定的类。例如:
from typing import Any, Dict, Optional
鉴于这种typing
的方式会将项添加到本地名称空间,所以导入中的任何名称都应该与关键字类似,并且不能在您的Python代码中定义,无论是否导入。如果模块中的类型和现有名称之间存在冲突,请使用import x as y
。
from typing import Any as AnyType
如果需要在运行时避免类型检查所需的附加导入,则可以使用条件导入。不鼓励这种模式,并且应该优先选择重构代码以允许顶级导入的替代方案。如果完全使用这种模式,那么有条件地导入的类型需要被引用为字符串'sketch.Sketch'
而不是sketch.Sketch
,以与Python 3向前兼容,其中注释表达式被实际评估。 只有type注释才需要的导入可以放在一个if typing.TYPE_CHECKING:
块中。
- 应该在这里定义仅用于设置的实体;这包括别名。否则,它将成为运行时错误,因为模块不会在运行时导入。
- 块应该在所有正常导入。
- 类型导入列表中不应该有空行。
- 将列表排序,就好像它是一个常规导入列表一样,但是将末尾的输入模块导入。
google3
模块也有一个TYPE_CHECKING
常量。 如果你不想在运行时typing
输入,你可以使用它。import typing...if typing.TYPE_CHECKING:import typesfrom MySQLdb import connectionsfrom google3.path.to.my.project import my_proto_pb2from typing import Any, Dict, Optional
循环依赖
由键入代码的循环依赖。这样的代码是重构的好选择。 尽管技术上可以保持循环依赖,但构建系统不会让你这么做,因为每个模块都必须依赖于其他模块。
使用Any替换创建循环依赖项导入的模块。设置有意义的名称用别名,并使用此模块中的实际类型名称(任何属性均为Any)。 别名定义应该与上一次导入分开一行。
from typing import Anysome_mod = Any # some_mod.py imports this module.......
总结
请务必保持代码的一致性
如果你正在编辑代码, 花几分钟看一下周边代码, 然后决定风格. 如果它们在所有的算术操作符两边都使用空格, 那么你也应该这样做。如果它们的注释都用标记包围起来, 那么你的注释也要这样。
制定风格指南的目的在于让代码有规可循, 这样人们就可以专注于”你在说什么”, 而不是”你在怎么说”. 我们在这里给出的是全局的规范, 但是本地的规范同样重要. 如果你加到一个文件里的代码和原有代码大相径庭, 它会让读者不知所措。 避免这种情况。
注:
原文来自于Google PyGuid
参考译文来自于Google Python Style Guide