idea 中 findBugs 插件的 详细配置

参考

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报告任何结果。

 

Share

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中多个其余的对象所共有，这样在其余代码中会引发死锁。

I18N

国际化

 

推荐阅读

FindBugs 规则整理

FindBugs：简介与使用
FindBugs 规则整理：CORRECTNESS
FindBugs 规则整理：Bad Practice
FindBugs 规则整理：Style & Dodgy
FindBugs 规则整理：Malicious Code Vulnerability
FindBugs 规则整理：Security & Experimental
FindBugs 规则整理：Performance

FindBugs 规则整理：Multithreaded Correctness
FindBugs 规则整理：Internationalization

 

https://blog.csdn.net/jdsjlzx/article/details/21472253/