CheckStylePMDFindBugs使用总结.docx

上传人:b****7 文档编号:9242257 上传时间:2023-02-03 格式:DOCX 页数:23 大小:25.35KB
下载 相关 举报
CheckStylePMDFindBugs使用总结.docx_第1页
第1页 / 共23页
CheckStylePMDFindBugs使用总结.docx_第2页
第2页 / 共23页
CheckStylePMDFindBugs使用总结.docx_第3页
第3页 / 共23页
CheckStylePMDFindBugs使用总结.docx_第4页
第4页 / 共23页
CheckStylePMDFindBugs使用总结.docx_第5页
第5页 / 共23页
点击查看更多>>
下载资源
资源描述

CheckStylePMDFindBugs使用总结.docx

《CheckStylePMDFindBugs使用总结.docx》由会员分享,可在线阅读,更多相关《CheckStylePMDFindBugs使用总结.docx(23页珍藏版)》请在冰豆网上搜索。

CheckStylePMDFindBugs使用总结.docx

CheckStylePMDFindBugs使用总结

1.PMD,FindBugs,CheckStyle三者的的比较

工具

目的

检查项

FindBugs

检查.class

基于BugPatterns概念,查找java字节码(.class文件)中的潜在bug

主要检查bytecode中的bugpatterns,如NullPoint空指针检查、没有合理关闭资源、字符串相同判断错(==,而不是equals)等

PMD

检查源文件

检查Java源文件中的潜在问题

主要包括:

空try/catch/finally/switch语句块

未使用的局部变量、参数和private方法

空if/while语句

过于复杂的表达式,如不必要的if语句等

复杂类

CheckStyle

检查源文件

主要关注格式

检查Java源文件是否与代码规范相符

主要包括:

Javadoc注释

命名规范

多余没用的Imports

Size度量,如过长的方法

缺少必要的空格Whitespace

重复代码

1.PMD

1.1Ant配置

以Ant方式运行PMD规则,以下是Ant配置文件build.xml:

1.2自定义PMD规则

PMD自带了很多规则集合,并且分类写入不同的ruleset文件。

其中basic.xml包含了一般要遵守的最佳代码实践,详细规则描述参见PMD规则总结.xlsx.

自定义PMD规则集,根据项目需要,用如下方式修改Ant指定的PMD规则文件favorites.xml:

--使用整个strings规则集-->

--使用某个规则集里的某个规则-->

--指定某个规则集里的某个规则的优先级-->

2

--去除某个规则集里的某个规则-->

2.FindBugs

2.1Ant配置

--includeFilter指定要包含的规则的过滤器文件,excludeFilter包含要去除的规则过滤器文件-->

includeFilter="${findbugs_include_filter}"

excludeFilter="${findbugs_exclude_filter}"

jvmargs="-Xmx384m"output="html"

outputFile="d:

/test.html">

--定义findbugs查找的类路径-->

--定义上述类所依赖的类路径-->

--定义源代码的路径-->

2.2自定义FindBugs规则

使用过滤器我们就可以定义使用哪些bug检测器和针对哪些类进行检查,过滤器实际是在一个xml文件定义的,即上述Ant配置文件中的findbugs_inlude_filter.xml和findbugs_exclude_filter.xml,配置文件的内容如下:

--所有类使用bugcode为HE的检测器-->

--该类使用所有的bug检测器-->

--该类使用bugcode为HE的检测器-->

--该类的AMethod和BMethod方法使用bugcode为HE的检测器-->

2.3findbugs过滤器文件简介

2.3.1Match短语的element:

(1),它的属性有pattern,code,category并且粒度依次增大。

pattern-thetypeattributeofBugInstanceelements

—该类的指定方法使用bug模式为OS_OPEN_STREAM的检测器-->

code-bugabbreviations

--该类通过指定缩写名使用一些bug检测器-->

category-CORRECTNESS,MT_CORRECTNESS,BAD_PRACTICICE,PERFORMANCE,STYLE

--所有类通过指定检测器种类使用某些检测器-->

为了兼容以前版本,使用代替,他们有个name属性,如:

--该类使用bugcode为HE的检测器-->

(2)

属性:

value,是一个整数,1tomatchhigh-prioritywarnings,2tomatchmedium-prioritywarnings,or3tomatchlow-prioritywarnings.

(3)

属性:

name,其值是特定的包名或匹配包名的正则表达式。

(4)

属性:

name,其值是特定的类名或匹配类名的正则表达式。

为了兼容以前的版本,可以在元素上使用属性class和classregex。

(5)

属性:

name:

其值是特定的方法名或匹配方法名的正则表达式。

Params:

以逗号分隔的方法参数类型。

Returns:

方法返回类型。

注:

在params和returns属性中,类名必须写全。

(E.g.,"java.lang.String"insteadofjust"String".)

(6)

属性:

name,type

(7)

指定一个局部变量。

属性:

name

(8)

连接各种matchelement.

2.3.2一些例子

--该类使用所有的bug检测器-->

--该类使用bugcode为HE的检测器-->

--该类通过指定缩写名使用一些bug检测器-->

--所有类使用bugcode为HE的检测器-->

--所有类使用bugcode为DE,UrF,SIC的检测器-->

--所有类通过指定检测器种类使用某些检测器-->

--该类的指定方法使用bugcode为DC的检测器-->

--该类的AMethod和BMethod方法使用bugcode为DE,UrF,SIC的检测器-->

--该类的指定方法使用bug模式为OS_OPEN_STREAM的检测器-->

--该类的某个方法使用优先级为2的bug模式DLS_DEAD_LOCAL_STORE的检测器-->

--代码的指定部分使用指定bugcode或bug模式的检测器-->

--所有包的信息类使用bugcode为UUF的检测器-->

--所有内部包使用bugcode为MS的检测器-->

--ui包层使用bug模式为SIC_INNER_SHOULD_BE_STATIC_ANON的检测器-->

--带指定标志的成员域或方法使用指定bugcode或bug模式的检测器-->

--所有类中的voidmain(String[])方法使用bug模式为DM_EXIT的检测器-->

--所有类中的com.foobar.DebugInfo型的域使用bugcode为UuF的检测器-->

2.4FindBugsBug描述

Findbugs是一个静态分析工具,它检查*.class文件或者JAR文件,将字节码与一组缺陷模式进行对比以发现可能的问题。

Findbugs自带检测器,其中有60余种Badpractice,80余种Correctness,1种Internationalization,12种Maliciouscodevulnerability,27种Multithreadedcorrectness,23种Performance,43种Dodgy。

FindBugs可以做什么?

找出hashequals不匹配

检测:

忽略方法返回值

检测:

Null指针对null的解引用(dereference)和冗余比较

检测:

初始化之前读取字段

命名检查

未使用的代码检查

嵌套检查

导入语句检查

JUnit测试检查

字符串检查

括号检查

代码尺寸检查

终结函数检查

克隆检查

耦合检查

异常检查

日志检查

Open—Close检查

 其它检查

其它缺陷

构建自己的规则集

Badpractice坏的实践

一些不好的实践,下面列举几个:

HE:

类定义了equals(),却没有hashCode();或类定义了equals(),却使用

Object.hashCode();或类定义了hashCode(),却没有equals();或类定义了hashCode(),却使用Object.equals();类继承了equals(),却使用Object.hashCode()。

SQL:

Statement的execute方法调用了非常量的字符串;或PreparedStatement是由一个非常量的字符串产生。

DE:

方法终止或不处理异常,一般情况下,异常应该被处理或报告,或被方法抛出。

Correctness一般的正确性问题

可能导致错误的代码,下面列举几个:

NP:

空指针被引用;在方法的异常路径里,空指针被引用;方法没有检查参数是否null;null值产生并被引用;null值产生并在方法的异常路径被引用;传给方法一个声明为@NonNull的null参数;方法的返回值声明为@NonNull实际是null。

Nm:

类定义了hashcode()方法,但实际上并未覆盖父类Object的hashCode();类定义了tostring()方法,但实际上并未覆盖父类Object的toString();很明显的方法和构造器混淆;方法名容易混淆。

SQL:

方法尝试访问一个PreparedStatement的0索引;方法尝试访问一个ResultSet的0索引。

UwF:

所有的write都把属性置成null,这样所有的读取都是null,这样这个属性是否有必要存在;或属性从没有被write。

Internationalization国际化

当对字符串使用upper或lowercase方法,如果是国际的字符串,可能会不恰当的转换。

Maliciouscodevulnerability可能受到的恶意攻击

如果代码公开,可能受到恶意攻击的代码,下面列举几个:

FI:

一个类的finalize()应该是protected,而不是public的。

MS:

属性是可变的数组;属性是可变的Hashtable;属性应该是packageprotected的。

Multithreadedcorrectness多线程的正确性

多线程编程时,可能导致错误的代码,下面列举几个:

ESync:

空的同步块,很难被正确使用。

MWN:

错误使用notify(),可能导致IllegalMonitorStateException异常;或错误的

使用wait()。

No:

使用notify()而不是notifyAll(),只是唤醒一个线程而不是所有等待的线程。

SC:

构造器调用了Thread.start(),当该类被继承可能会导致错误。

Performance性能问题

可能导致性能不佳的代码,下面列举几个:

DM:

方法调用了低效的Boolean的构造器,而应该用Boolean.valueOf(…);用类似

Integer.toString

(1)代替newInteger

(1).toString();方法调用了低效的float的构造器,应该用静态的valueOf方法。

SIC:

如果一个内部类想在更广泛的地方被引用,它应该声明为static。

SS:

如果一个实例属性不被读取,考虑声明为static。

UrF:

如果一个属性从没有被read,考虑从类中去掉。

UuF:

如果一个属性从没有被使用,考虑从类中去掉。

Dodgy危险的

具有潜在危险的代码,可能运行期产生错误,下面列举几个:

CI:

类声明为final但声明了protected的属性。

DLS:

对一个本地变量赋值,但却没有读取该本地变量;本地变量赋值成null,却没有读取该本地变量。

ICAST:

整型数字相乘结果转化为长整型数字,应该将整型先转化为长整型数字再相乘。

INT:

没必要的整型数字比较,如X<=Integer.MAX_VALUE。

NP:

对readline()的直接引用,而没有判断是否null;对方法调用的直接引用,而方法可能返回null。

REC:

直接捕获Exception,而实际上可能是RuntimeException。

      ST:

从实例方法里直接修改类变量,即static属性。

3.CheckStyle

3.1Ant配置

--指定一个taskdef来定义checkstyle任务-->

--自定义扫描文件my_check.xml,failOnViolation遇到错误是否停止扫描-->

--指定要扫描的源文件,指定写结果的文件类型-->

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 考试认证 > 交规考试

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1