1.4 编码风格与自动检查

没错,编码风格是一个不太讨巧的话题,不过这里仍然要聊一下。

Python具有其他语言少有的绝佳质量1:使用缩进来定义代码块。乍一看,似乎它解决了一个由来已久的“往哪里放大括号?”的问题,然而,它又带来了“如何缩进?”这个新问题。

广告:个人专属 VPN,独立 IP,流量大,速度快,连接稳定,多机房切换,每月最低仅 10 美元

而Python社区则利用他们的无穷智慧,提出了编写Python代码的PEP 82(http://www.python.org/dev/peps/pep-0008/)标准。这些规范可以归纳成下面的内容。

 
  • 每个缩进层级使用4个空格。
  • 每行最多79个字符。
  • 顶层的函数或类的定义之间空两行。
  • 采用ASCII或UTF-8编码文件。
  • 在文件顶端,注释和文档说明之下,每行每条import语句只导入一个模块,同时要按标准库、第三方库和本地库的导入顺序进行分组。
  • 在小括号、中括号、大括号之间或者逗号之前没有额外的空格。
  • 类的命名采用骆驼命名法,如CamelCase;异常的定义使用Error前缀(如适用的话);函数的命名使用小写字符,如separated_by_underscores;用下划线开头定义私有的属性或方法,如_private

这些规范其实很容易遵守,而且实际上很合理。大部分程序员在按照这些规范写代码时并没有什么不便。

然而,犯错在所难免,保持代码符合PEP 8规范的要求仍是一件麻烦事。工具pep8(https://pypi.python.org/pypi/pep8)就是用来解决这个问题的,它能自动检查Python文件是否符合PEP 8要求,如示例1.1所示。

示例1.1 运行pep8

$ pep8 hello.py 
hello.py:4:1: E302 expected 2 blank lines, found 1 
$ echo $? 
1

pep8会显示在哪行哪里违反了PEP 8,并为每个问题给出其错误码。如果违反了那些必须遵守的规范,则会报出错误(以E开头的错误码),如果是细小的问题则会报警告(以W开头的错误码)。跟在字母后面的三位数字则指出具体的错误或警告,可以从错误码的百位数看出问题的大概类别。例如,以E2开头的错误通常与空格有关,以E3开头的错误则与空行有关,而以W6开头的警告则表明使用了已废弃的功能。

社区仍然在争论对并非标准库一部分的代码进行PEP 8验证是否是一种好的实践。这里建议还是考虑一下,最好能定期用PEP 8验证工具对代码进行检测。一种简单的方式就是将其集成到测试集中。尽管这似乎有点儿极端,但这能保证代码一直遵守PEP 8规范。6.7节中将介绍如何将pep8与tox集成,从而让这些检查自动化。

OpenStack项目从一开始就通过自动检查强制遵守PEP 8规范。尽管有时候这让新手比较抓狂,但这让整个代码库的每一部分都保持一致,要知道现在它有167万行代码。对于任何规模的项目这都是非常重要的,因为即使对于空白的顺序,不同的程序员也会有不同的意见。

也可以使用--ignore选项忽略某些特定的错误或警告,如示例1.2所示。

示例1.2 运行pep8时指定--ignore选项

$ pep8 --ignore=E3 hello.py 
$ echo $? 
0

这可以有效地忽略那些不想遵循的PEP 8标准。如果使用pep8对已有的代码库进行检查,这也可以暂时忽略某些问题,从而每次只专注解决一类问题。

 注意

  如果正在写一些针对Python的C语言代码(如模块),则PEP 7(http://www.python.org/dev/peps/pep-0007/)标准描述了应该遵循的相应的编码风格。

还有一些其他的工具能够检查真正的编码错误而非风格问题。下面是一些比较知名的工具。

 

这些工具都是利用静态分析技术,也就是说,解析代码并分析代码而无需运行。

如果选择使用pyflakes,要注意它按自己的规则检查而非按PEP 8,所以仍然需要运行pep8。为了简化操作,一个名为flake8(https://pypi.python.org/pypi/flake8)的项目将pyflakes和pep8合并成了一个命令,而且加入了一些新的功能,如忽略带有#noqa的行以及通过入口点(entry point)进行扩展。

为了追求优美而统一的代码,OpenStack选择使用flake8进行代码检查。不过随着时间的推移,社区的开发者们已经开始利用flake8的可扩展性对提交的代码进行更多潜在问题的检查。最终flake8的这个扩展被命名为hacking(https://pypi.python.org/pypi/hacking)。它可以检查except语句的错误使用、Python 2与Python 3的兼容性问题、导入风格、危险的字符串格式化及可能的本地化问题。

如果你正开始一个新项目,这里强烈建议使用上述工具之一对代码的质量和风格进行自动检查。如果已经有了代码库,那么一种比较好的方式是先关闭大部分警告,然后每次只解决一类问题。

尽管没有一种工具能够完美地满足每个项目或者每个人的喜好,但flake8和hacking的结合使用是持续改进代码质量的良好方式。要是没想好其他的,那么这是一个向此目标前进的好的开始。

 提示

  许多文本编辑器,包括流行的GNU Emacs(http://www.gnu.org/software/emacs/)和vim(http://www.vim.org/),都有能够直接对代码运行pep8和flake8这类工具的插件(如Flymake),能够交互地突出显示代码中任何不兼容PEP 8规范的部分。这种方式能够非常方便地在代码编写过程中修正大部分风格错误。

1你可能有不同意见。
2 PEP 8 Style Guide for Python Code, 5th July 2001, Guido van Rossum, Barry Warsaw, Nick Coghlan