常用JAVA代码质量静态检查工具概要1.pptVIP

THE END 谢谢！ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 目录 软件开发经历反省 我们代码中常见几类问题 Quality Metrics Tools CheckStyle PMD FindBugs 我们代码中常见几类问题 使用了不规范的变量和方法名 EsbResultModel validRule(HashMap orderInfo, ArrayList orderItems, String Role); String role要小写 类、public 方法和常量javadoc的缺失 javadoc中的声明跟实际的方法不一致，例如方法实际只有1个参数，而javadoc里@param定义了多个（估计是方法签名的时候没有同步的修改javadoc） 我们代码中常见几类问题 错误的使用/** */ 和/* */ 很多public方法和常量使用了/* */来注释，导致注释内容不能被写入javadoc。而另一方面是错误使用/** */导致错误的内容被写入javadoc 存在未被使用的方法和变量 这些不被使用方法和变量名会增加日后bug修改、代码维护的成本\ 方法超长 一个方法超过150行，是不是太长太复杂了?。 我们代码中常见几类问题 代码中有不少magic-number和magic-string 刘谦的魔术不好看，所以如果你维护的代码跟刘谦的一样，估计你也会抓狂的！ String s = “0000” + Integer.toString(ch, 16); 0000是什么，16是啥东东，就算是作者3个礼拜也不记得当初写这段代码的用意了。 Import了一些不需要的类 提交代码以前请务必Organize Imports。 我们代码中常见几类问题 有些代码的写法不容易理解 不一致的代码风格 例如，String oneitems[] vs String[] oneitems 前者是C/C++的编码风格；咱们写的是java，就统一用String[] oneitems吧。 NO EXCUTABLE Why using Quality Metrics Tools 一个软件的生命周期中，80%的花费在于维护 几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护 编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码 …… CheckStyle CheckStyle用来检查代码格式、规范、风格 检查并强制执行统一的代码风格 检查Javadoc 检查类、变量、方法的命名 检查类和方法的大小 检查编码错误，例如magic number …… Checkstyle-安装 Eclipse插件地址 /update Checkstyle-启用 Checkstyle—配置规范 Checkstyle使用效果 黄色的区域就是checkstyle检查出有问题的地方（红色表示错误，黄色表示警告）。 Checkstyle-注意事项 修改Eclipse Java Code Style Formatter配置，由于Eclipse默认设置换行后的缩进符号为tab ，而Java规范不允许代码中有tab，因为tab在不同的操作系统下的长度占位不同，有的是4个空格，有的是8个空格，因此我们要修改这个配置为空格。 Checkstyle-注意事项 PMD PMD提供了一些开发过程中的最佳实践。 Possible bugs - empty try/catch/finally/switch statements Dead code - unused local variables, parameters and private methods Suboptimal code - wasteful String/StringBuffer usage Overcomplicated expressions - unnecessary if statements, for loops that could be while loops Duplicate code - copied/pasted code means copied/pasted bugs PMD-Exception 规则 AvoidCatchingThrowable SignatureDeclareThrowsException ExceptionAsFlowControl AvoidThrowingRawExceptionTypes AvoidThrowingNullPointerException AvoidRethrow