idea 中 findBugs 插件的详细配置

最新推荐文章于 2023-02-07 20:14:42 发布

weixin_33725722

最新推荐文章于 2023-02-07 20:14:42 发布

阅读量860

点赞数

文章标签：开发工具 ui 移动开发

原文链接：https://my.oschina.net/viakiba/blog/1838324

版权

2019独角兽企业重金招聘Python工程师标准>>>

参考

https://my.oschina.net/viakiba/blog/1838327

http://findbugs.sourceforge.net/manual/index.html

界面如下

General

这一栏总共有五项

1.Compile affected files before analyze 在分析之前进行编译

2. Analyze affect files affter comlplie 在变动的文件编译之后分析自动

3. Analyze affect files after auto make 在自动Make之后分析变动的文件自动

4. Run analyze in background 在后台分析，不显示进度条窗口

5. Active toolwindow on run 按钮是否展示

下面的Plugins 点击加号添加如下插件

fb-contrib 是 findBugs 的一个扩展的bug探测器

find Security Bugs 针对安全问题的探测

FindBugs for android 编码安全问题针对Android。

Detector 探测器

Disabled detectors will not participate in the analysis.
'Grayed out' detector will run, however they will not report any result to the UI

即

禁用的检测器将不参与分析。
“灰色”检测器将运行，但是它们不会向UI报告任何结果。

This setting file will be imported before the analyze is started. The current settings will be overwritten. Sonar and findbugs-idea setting file format is supported. This might primarily be a good solution to share Sonar setting file.

在开始分析之前，将导入此设置文件。当前的设置将被覆盖。Sonar和FunBug理念设置文件格式是支持的。这可能是共享Sonar设置文件的一个很好的解决方案。
在FunBug想法设置文件的情况下，可以更好地与官方解决方案共享“FunBugSig.xml”（在.IDEA项目目录内）。

Report

Analysis effort

分析级别可选项： Minimal/default/Maximal

Minimum rank

配置的错误级别数字越小越严重配置数字越小筛选的范围越小

Minimum confidence

匹配具有特定错误等级的警告。 1 hign/2 medium /3 low

Bad pratice

编程的坏习惯
主要是命名问题,比如类名最好以大写开头,字符串不要使用等号不等号进行比较,可能会有异常最好用try-catch包裹的代码,方法有返回值但被忽略等等,这些如果不想改可以直接忽略.

Malicious code vulnerability

恶意代码漏洞
听起来很吓人呀,主要是一些属性直接使用public让别的类来获取,建议改为private并为其提供get/set方法.
还有一些public的静态字段,可能会被别的包获取之类的.
这些也需要根据项目具体情况来,个人意见,在有的不重要类,有时直接公开使用属性,可能更为便捷.如果你认为这些不需要修改,完全可以忽略.

correctness

代码的正确性这一项应该算是最重要的了

主要是没有对变量进行不为空判定,在特殊情况可能发生空指针异常.

performance

性能

主要是一些无用的代码,比如声明了没有用到的属性等等

security

安全

Dodgy code

糟糕的代码

·比如一个double/float被强制转换成int/long可能会导致精度损失,一些接近零的浮点数会被直接截断,事实上我们应该保留.

这里顺便提一点,这两天看了《app研发录》,在规范代码,尽量规避错误这方面我也有了一些收获.

在类型转换的时候,我们应该为类型转换提供一个安全的转换方法,因为我们永远不会知道,我们的app在用户手里会发生什么,所以我们要尽可能的去减少这种发生错误的可能.

·比如使用switch的时候没有提供default。

·多余的空检查，就是不可能为空的值，增加了不为空判断，这是没有必要的。属于代码冗余

·不安全的类型转换等等。

这项太多了，就不一一列举了。

Experimental

实验（参考 https://blog.csdn.net/jdsjlzx/article/details/21472253/）

1.LG: Potential lost logger changes due to weak reference in OpenJDK (LG_LOST_LOGGER_DUE_TO_WEAK_REFERENCE)
OpenJDK的引入了一种潜在的不兼容问题，特别是，java.util.logging.Logger的行为改变时。它现在使用内部弱引用，而不是强引用。–logger配置改变，它就是丢失对logger的引用，这本是一个合理的变化，但不幸的是一些代码对旧的行为有依赖关系。这意味着，当进行垃圾收集时对logger配置将会丢失。例如：
public static void initLogging() throws Exception {
Logger logger = Logger.getLogger("edu.umd.cs");
logger.addHandler(new FileHandler()); // call to change logger configuration
logger.setUseParentHandlers(false); // another call to change logger configuration
}
该方法结束时logger的引用就丢失了，如果你刚刚结束调用initLogging方法后进行垃圾回收，logger的配置将会丢失（因为只有保持记录器弱引用）。
public static void main(String[] args) throws Exception {
initLogging(); // adds a file handler to the logger
System.gc(); // logger configuration lost
Logger.getLogger("edu.umd.cs").info("Some message"); // this isn't logged to the file as expected
}
2.OBL: Method may fail to clean up stream or resource (OBL_UNSATISFIED_OBLIGATION)
这种方法可能无法清除（关闭，处置）一个流，数据库对象，或其他资源需要一个明确的清理行动。
一般来说，如果一个方法打开一个流或其他资源，该方法应该使用try / finally块来确保在方法返回之前流或资源已经被清除了。这种错误模式基本上和OS_OPEN_STREAM和ODR_OPEN_DATABASE_RESOURCE错误模式相同，但是是在不同在静态分析技术。我们正为这个错误模式的效用收集反馈意见。

Multithreaded Correctness

多线程问题

DL_SYNCHRONIZATION_ON_BOOLEAN
Synchronization on Boolean could lead to deadlock
该代码同步一个封装的原始常量，例如一个Boolean类型
private static Boolean inited = Boolean.FALSE; ... synchronized(inited) { if (!inited) { init(); inited = Boolean.TRUE; } } ...
由于通常只存在两个布尔对象，此代码可能是同步的其他无关的代码中相同的对象，这时会导致反应迟钝和可能死锁

DL_SYNCHRONIZATION_ON_BOXED_PRIMITIVE
Synchronization on boxed primitive could lead to deadlock
该代码同步一个封装的原始常量，例如一个Integer类型。
private static Integer count = 0; ... synchronized(count) { count++; } ...
由于Integer对象可以共享和保存，此代码可能是同步的其他无关的代码中相同的对象，这时会导致反应迟钝和可能死锁

DL_SYNCHRONIZATION_ON_SHARED_CONSTANT
Synchronization on interned String could lead to deadlock
同步String类型的常量时，由于它被JVM中多个其他的对象所共有，这样在其他代码中会引起死锁。