课件

2.4 代码静态检查.pdf

代码评审技术

代码审查是指通过阅读代码来检查源代码和编程规范是否符合，以及代码本身质量的一种活动，它被公认为是一个提高代码质量的有效手段，这种活动比较容易发现架构和时序相关的较难发现的一些问题，同时还可以帮助团队成员统一编程风格，提高编程技能等。

缺陷检查表

代码审查主要是检查代码编写的规范性、代码设计的合理性、以及处理代码中的一些地雷区，也就是一些最常出错但测试不容易发现的地方，上图所示我们给大家列出了一部分示例的问题，在实际的开发中需要大家根据项目的要求和实践经验进行进一步的归纳总结。

编程规范：是最基本的检查项，主要是检测源代码是否符合具体编程语言的规范要求；
面向对象设计：检测设计抽象是否合理，是否考虑了未来扩展性的要求；
性能：主要是检查代码实现中是否存在性能问题，比如说数据结构的选择、线程和缓存的使用，以及并发访问策略等，这里并不考虑架构和功能方面的性能问题；
资源释放处理：内存也是影响效率和可靠性的主要因素，重点是要检查内存的申请和释放是否正确，是否存在内存泄露的问题；
程序流程：检查程序处理逻辑是否正确，尤其是循环的结束条件，以及循环处理是否存在影响性能的问题；
线程安全：线程处理是否存在安全和死锁的问题；
数据库处理：数据库的处理是否正确，尤其是事务的完整性和隔离性方面的问题；
通讯方面：通讯的编程实现机制是否合理；
JAVA对象处理：具体的编程语言中，对象的创建和删除是否正确；
异常处理：也是一个重要的检查项，主要是检查异常处理是否考虑了所有可能的错误并且处理正确；
方法（函数）：方法或函数的检测重点在于接口参数、变量初始化等；
代码安全：主要涉及参数合法性检查、信息加密和通讯安全等问题；
其他：其他方面还有一些关于日志、配置等方面的问题；

Python代码分析工具

在代码审查过程中，我们可以借助工具来帮助自动地执行静态代码分析，以便快速定位代码中隐藏的错误和缺陷，减少人工逐行检查上花费的时间，提高代码审查的效率。

Pylint：http://www.pylint.org

Pylint 是一个 Python 代码静态分析工具，它用于分析 Python 代码的错误，查找不符合代码风格标准（Pylint 默认使用的代码风格是 PEP 8）和有潜在问题的代码。

下面我们简单介绍一下如何使用这个工具进行代码检查。

Pylint的功能主要包括三个方面：

第一是对代码风格进行检查，主要是检查代码是否符合PEP8规范。
第二是检查代码中是否存在一些常见的错误，比如说是否所有变量在访问之前都已经定义等等，大家可从 http://pylint-messages.wikidot.comlall-messages 里面看到一个完整的检查列表。
第三是检查代码中是否存在重复代码，以便为重构提供帮助。

Pylint的安装很简单，可以通过Python的包管理工具pip进行安装，另外只要在命令行中输入「Pylint + 选项 + 要检查的模块包或者文件的名称」，就可以使用Pyint进行检查：

Pvlint常用的选项有以下几项：

rcfile用来指定检查时所用的配置文件，默认是当前目录下的Pylintrc文件；
ignore用来指定不进行检查的文件列表；
disable用来关闭某种类型的检查；
f指定报告的类型，默认情况下是文本类型，我们可以通过 -f 来输出html格式的报告；

Pylint 安装与使用

Pylint还有一些其他命令，比如help参数是用以查看某种类型问题的帮助信息：

这里给出的例子是一个查看关于无效命名的说明。

generate是根据当前配置生成配置文件，默认情况下使用当前目录下的Pylintrc文件作为配置：

有关Pylint命令及其使用的详细说明可以查阅官方文档。

下面通过一个简单的例子来说明Pylint的使用。

这段程序的功能是凯撒密码的加密解密，我们在命令行中输入Pylint命令：

pylint simplecaeser.py

对这段程序进行静态分析，输出结果分为两部分，一个是源代码的分析部分，另一个是一系列详细报告。

下面我们先来看下源代码分析部分，第一行是说没有找到配置文件，这里使用默认配置，下面红框部分是检查到的问题列表，它按照错误类型、出现位置、说明信息这样的格式列出的，主要的错误类型包括：

约定Convention：指违反了编码标准；
重构Refactor：是写的很糟糕的代码；
警告Warning：是某些Python特定的问题；
错误Error：是指代码中可能有的错误；

源代码分析部分的下面就是一系列的报告：

第一行是总计分析了多少行语句，本例子中是20行语句。
图1表格列出了所查文件的模块、类、方法和函数的数量。
图2左上方的表列出了实际代码、文档字符串、注释、空行等分别有多少行以及所占的百分比，本例子中代码是22行占95.65%，没有docstring，一般的注释有一行，还有显示前一次结果，可用来做对比。
图2左下方的表显示是否有重复的代码行，本例子是没有重复代码的。
图2右上方的表是对前面的源代码分析信息进行汇总，分别按照不同的错误类型，列出各是多少。
图2右下方的表是根据问题的标识进行汇总。
最后，在最下方，Pyint会给出一个评分，10分是满分，还会把这一次的得分和前面的结果做比较，因为我们这里的程序是第一次运行，所以得分的变化是零。

案例：生命游戏

现在我们对之前介绍的生命游戏程序进行静态分析，下面看一下分析结果。

第一类问题就是行过长，PEP8规定每行代码长度一般不超过79个字符，最长不超过100个字符，Pylint会检查是否有代码的宽度超过100个字符，图中可以看到项目中有2行代码超过了100，过长的代码会造成阅读的困难，降低可读性。

第二类问题是缺少docstring，一般情况下，模块和公共方法、函数都要添加docstring。

第三类问题是不合法的命名，默认的配置中，变量名至少需要三个字符，所以这里的d和nc都不符合规则。

bad-builtin是说明使用了不好的内置函数，例如map和filter，这是因为Pylint认为使用Python的列表推导更符合Python的习惯，列表推导通常具有较好的可读性，并且会有少量的性能提升。

bare-except是指在使用try except捕捉异常时，没有指定异常类型，通常我们都应该明确异常类型并进行处理。

下面我们对代码检查的错误进行修改。

行过长的问题可以通过换行使行变短，例如这样的修改：

缺少docstring的问题应该是补充有意义的说明，这里暂时关闭这项检查，但是在实际开发中不建议这样做。无效命名的问题要具体分析原因，我们这里是把命名规则进行重新设定：

关于bare-except问题，生命游戏这个程序没有必要在except中做异常处理，相应的处理已经在主函数中实现，所以可以关闭这项检查。在某些情况下可能需要关闭某个文件中的某些警告信息，这种情况往往不是配置文件中那种全局配置的情况，那么我们可以通过下面的方式来实现，并且在文件头加上注释：

现在生命游戏的评分达到了10分：

代码静态分析工具

各种不同的编程语言都有自己的静态分析工具，这里列出的是Java语言的：

还有C++、JavaScript、HTML等：

建议大家结合具体的编程学习使用。

代码审查实践

代码审查已经被广泛地公认为是一种非常好的工程实践，在Google公司任何产品任何项目的程序代码，都要在经过有效的代码审查之后，才能提交到代码库中，也正是因为这种很彻底很普遍的应用，让Google的程序变得非常优秀。

如果你在编程的时候，知道会有同事检查你的代码，那么你的编程态度就会完全不一样，你写出的代码将会更加的整洁，有更好的注释和更好的结构，希望同学们在编程实践中学会应用这种做法，不断地提升编写高质量代码的能力。