代码审查参考文档
代码审查（code review）是保证软件质量的一个重要环节，通过审查代码能够发现代码中可能存在的问题并给予纠正，这些问题可能包括设计上的、实现上的或者编程风格等多方面。本文档通过列举代码编写过程中的一些常见的细节问题，为代码审查环节提供参考。
Java代码
一、对象和变量
1.存在未被使用的变量
Eclipse会自动用下划线标出
2.对象的重复创建
这是系统中普遍存在的问题，比如：
public class PrtGrpEndorsementBL {
private GlobalInput mGlobalInput = new GlobalInput();
private boolean getInputData(VData cInputData) {
mGlobalInput = (GlobalInput) cInputData.getObjectByObjectName( "GlobalInput", 0);
return true;
}
}
这里mGlobalInput对象属于重复创建，因为在getInputData方法里会对它进行赋值，mGlobalInput使用的应该是从jsp页面传入的对象，所以改为private GlobalInput mGlobalInput = null;
又如：
String msg = "";
if (..) {
msg = "A";
}
else {
msg = "B";
}
这里msg同样属于重复创建，改为String msg = null;
3.变量的作用域
Java的局部变量可以定义在函数的任何位置，有部分由c转学java的程序员习惯将变量都定义在函数的顶部，因为在c里只能那样定义。但实际上变量的作用域越短程序的内聚性就越高，耦合性也更低，程序更容易理解，因此在java里应该在使用前才定义变量。
4.局部变量的危害
定义过多的不必要的局部变量是造成系统难以维护的原因之一，因为每增加一个局部变量我们就要先化时间去理解这个局部变量的意思，因此我们要减少局部变量的使用。用函数的返回值来替代局部变量是一种有效的办法，这就需要我们用重构的方式从大的函数中提出小的函数，用小函数的返回值来替代原有的局部变量。把大函数分解本身也可以降低程序的耦合度。
二、常量
1.硬编码，将代码写死
比较严重的情况是将险种代码写死在程序中，比如：
if ("21301".equals(tLCGrpPolSchema.getRiskCode())) {
...
}
这里将“21301”写死会为系统的维护和升级带来很大困难，最好是以险种定义的形式去动态获取险种代码。如果实在描述有困难，可以考虑建立一个Constants常量类，将其以常量的形式定义，这样以后维护只需改动一处即可。
业务系统中存在不少的状态标志，比如AppFlag的状态”0”为未签单，”1”为已签单，”2”为保全增人。虽然这些状态的意义日后已没有改动的可能，但直接将”0”、”1”、”2”写在程序里会导致程序可读性差，因此我们同样可以将其定义在常量类中，并加上注释，这样我们不必每次都去翻看文档或pdm，看常量类里的注释就行了。
2.禁用常量接口
Java的常量有一种不好的用法，就是将常量定义在Inferface中，这种方使定义的常量在使用时可以省去类名前缀，但会为以后的维护带来麻烦。因此不要试图用继承的方式去使用常量。
三、数组
1.数组的定义
数组的定义采用String[] str = null; 的形式，而不是String str[] = null;
2.数组越界
数组越界是比较常见的错误，比如：
private void dealCont() {
LCContDB tLCContDB = new LCContDB();
tLCContDB.setGrpContNo(mGrpContNo);
tLCContSet = tLCContDB.query();
for (int i = 0; i < tLCContSet.size(); i++) {
LCContSchema tLCContSchema = tLCContSet.get(i);
LCPolDB tLCPolDB = new LCPolDB();
tLCPolDB.setContNo(tLCContSchema.getContNo());
LCPolSet tLCPolSet = tLCPolDB.query();
for (int j = 0; j < tLCPolSet.size(); j++) {
LCPolSchema tLCPolSchema = tLCPolSchema.get(i);
...
}
}
}
上面的程序就会产生数组越界，应该把tLCPolSchema.get(i);中的i改为j
数组越界的错误在编译时不会报错，直到程序运行时才会被发现。有一种方法可以避免此bug的产生，程序改为：
private void dealCont() {
LCContDB tLCContDB = new LCContDB();
tLCContDB.setGrpContNo(mGrpContNo);
tLCContSet = tLCContDB.query();
for (int i = 0; i < tLCContSet.size(); i++) {
dealPol(tLCContSet.get(i));
}
}
private void dealPol(LCContSchema tLCContSchema) {
LCPolDB tLCPolDB = new LCPolDB();
tLCPolDB.setContNo(tLCContSchema.getContNo());
LCPolSet tLCPolSet = tLCPolDB.query();
for (int i = 0; i < tLCPolSet.size(); i++) {
LCPolSchema tLCPolSchema = tLCPolSchema.get(i);
...
}
}
把内层循环提到一个函数中，在编译时就避免了bug的产生，而且降低了循环的层次，具有更好的可读性。
四、静态方法
1.静态方法的错误使用
com..lis.bq.ChangeCodeBL是保全中的一个工具类，它用两个重载了的静态方法getCodeName，它封装了CodeQueryBL类，其作用是根据code和codeType得到codeName，但是在使用过程中却出现了如下程序：
ChangeCodeBL tChangeCode = new ChangeCodeBL();
strArr[0] = "与被保人关系原为" + tChangeCode.getCodeName("relation",
tLCBnfSchema.getRelationToInsured())；
显然，作为静态方法getCodeName不应该这样使用，应改为：
strArr[0] = "与被保人关系原为" + ChangeCodeBL.getCodeName("relation",
tLCBnfSchema.getRelationToInsured())；
之所以出现这样的错误是因为ChangeCodeBL在定义构造函数时出了问题，构造函数的类型写成了public，但这个类实际上是不允许创建对象的。所以改为private ChangeCodeBL(){}就可以从根本上避免错误的产生。
静态方法的另一个常见的应用是用来创建对象，比如工厂模式和单例模式，这时我们同样应该使用pritvate的构造函数。
五、参数
1.对参数进行校验
对于传入类的参数，我们需要对其合法性进行校验，比如：
private boolean getInputData(VData cInputData) {
LCGrpContSchema tLCGrpContSchema =
(LCGrpContSchema) cInputData.getObjectByObjectName(
"LCGrpContSchema", 0);
LCContDB tLCContDB = new LCContDB();
tLCContDB.setGrpContNo(mGrpContSchema.getGrpContNo());
mLCContSet = tLCContDB.query();
return true;
}
这段代码是存在风险的，因为我们并不能保证getObjectByObjectName一定会得到一个对象返回，如果"LCGrpContSchema"写错了或者jsp页面根本就没有创建LCGrpContSchema 对象，那么tLCGrpContSchema就为null,执行到mGrpContSchema.getGrpContNo()时就会抛出空指针异常。
所以改为：
private boolean getInputData(VData cInputData) {
LCGrpContSchema tLCGrpContSchema =
(LCGrpContSchema) cInputData.getObjectByObjectName(
"LCGrpContSchema", 0);
if (tLCGrpContSchema == null) {
...
return false;
}
LCContDB tLCContDB = new LCContDB();
tLCContDB.setGrpContNo(mGrpContSchema.getGrpContNo());
mLCContSet = tLCContDB.query();
return true;
}
对于public的方法，我们同样需要对其参数进行校验，因为我们不能保证客户程序的调用是正确的。
2.不对参数进行赋值操作
Java中只有int，long，double等基本类型的参数是使用值传递，而对象参数都是传的地址，因此在函数中对对象参数赋值是无效的。C语言中由于有指针可以对函数外的对象的值直接进行修改，但java不行，因此参数只作为数据的传入而不能作为数据的传出。
六、代码简化
1.除去多余的代码
比如：
LCContDB tLCContDB = new LCContDB();
tLCContDB.setGrpContNo(tGrpContNo);
LCContSet tLCContSet = tLCContDB.query();
if ((tLCContSet == null) || (tLCContSet.size() == 0)) {
return false;
}
这里tLCContSet == null的判断是多余的，因为tLCContDB.query()肯定会创建一个对象返回，不存在返回null的情况，改为if (tLCContSet.size() == 0)
又如：
if (tLCPolSet.size() > 0) {
for (int i = 1; i <= tLCPolSet.size(); i++) {
tLPEdorItemSchema.setPolNo(tLCPolSet.get(i).getPolNo());
if (this.queryLPPol(tLPEdorItemSchema)) {
tLPPolSet.add(this.getSchema());
}
}
}
这里if (tLCPolSet.size() > 0)判断多余，将其除去
2.合并重复的代码
比如：
i f (getMoney > 0) {
strArr[0] = "本次申请应补交保费" +
setPrecision(Math.abs(getMoney), 2) + "元。";
tlistTable.add(strArr);
}
else {
strArr[0] = "本次申请应退还保费" +
setPrecision(Math.abs(getMoney), 2) + "元。";
tlistTable.add(strArr);
}
这里tlistTable.add(strArr);重复，将其提到if外面合并。
七、条件逻辑控制
1.去除控制标志
受结构化程序设计的影响，有人喜欢用boolean型的标志来控制程序的流程，比如：private boolean checkMoney() {
boolean flag = true;
if (money > 0){
flag = true;
}
else {
flag = false;
}
return flag;
}
但逻辑标志的使用会降低程序的可读性，当逻辑复杂时修改维护会比较困难，所以改为：private boolean checkMoney() {
if (money > 0){
return true;
}
else {
return flase;
}
}
或者：
private boolean checkMonay() {
if (money > 0){
return true;
}
return flase;
}
2.位运算符
&和|都是位运算符，但它们也可在if语句中进行条件判断，但此时仍是执行的位运算。
因为使用&和|容易引起不必要的错误，所以禁止在条件判断中使用位运算符。
八、异常处理
1.try{}catch{}语句的滥用
java的异常处理机制可以把错误处理程序和正常程序分开，使我们可以更容易进行复杂的错误处理。但异常处理机制容易被滥用，因为大多数的java书只是描述了异常机制的语法，而并没有说明什么情况下使用异常。异常之所以是异常是因为其不可预料性，比如我们通过io读取配置文件而文件并不存在，又比如通过jdbc读取数据库服务器却当掉了，这些都是需要我们通过异常机制来处理的情况。而下面的代码对异常的处理是错误的：private boolean getInputData(VData cInputData) {
try {
LCGrpContSchema tLCGrpContSchema =
(LCGrpContSchema) cInputData.getObjectByObjectName( "LCGrpContSchema", 0);
}
catch (Exception e) {
CError.buildErr(this, "接收数据失败");
return false;
}
return true;
}
因为我们只要看一下getObjectByObjectName的代码就知道这个函数如果处理错误会返
回一个null而不是抛出异常，这里的try{}catch{}是没有任何意义的，而且会降低程序的性能，因为对异常的捕获会花去额外的开销。
2.空指针异常
NullPointerException是比较常见的错误，因此我们在使用一个对象前一定要确保这个对象已经被创建过了。
3.数据格式化异常
使用Integer.parseInt(String s)进行数据格式转化时如果数据格式错误会抛出NumberFormatException异常，这个异常继承于RuntimeException，是一个非强制捕获的异常。但从程序的健壮性考虑，如下代码我们最好能进行异常处理：
将int bnfGrade = Integer.parseInt(tLPBnfSchema.getBnfGrade());改为：
try {
int bnfGrade = Integer.parseInt(tLPBnfSchema.getBnfGrade());
}
catch (NumberFormatException e) {
...
}
因为这里我们并不能保证tLPBnfSchema.getBnfGrade()返回的一定是可以被格式化为整数的字符串。如果我们有足够的理由确保这里不会产生异常，那么异常处理也可省略，正如前面所说的，异常处理的是不可预料的错误。
4.数组越界
数组越界异常同样容易被滥用，比如：
try {
int i = 0;
while(true) {
a[i++].f();
}
}
catch (ArrayIndexOutOfBoundsException e) {
...
}
这种用法是错误的，改为：
int k = a.length;
for (int i = 0; i < k; i++){
a[i].f();
}
不要试图用异常处理去取代条件判断，我们要做的是把数组越界的条件排除掉而不是等它越界了再去处理异常。
九、接口和抽象类
抽象和继承是面向对象的重要特征，使用接口和抽象类可以使得程序的实现细节得到封装，耦合度降低，更容易随着需求的变化而扩展。下面对一些需要注意的地方进行说明：
1.只从抽象类继承
使用继承时要慎重，继承代表“一般化/特殊化”的关系，继承会使子类依赖于父类，如果父类的实现发生改变那么子类的实现将不得不发生改变。因此，在使用继承时一般不要从具体类继承，只有抽象类才用来继承，因为抽象类可以用抽象方法来提供扩展，而抽象类里的具体方法一定要确保是需求比较固定的部分，以后都不会有任何的改动。
2.不覆写父类的具体方法
在子类中可以对父类的方法进行重载，也就是父类里实现了一个方法，子类用同样的函数名去重新实现这个方法。但这种做法是错误的，子类只应该去实现父类的抽象方法，而不是去实现父类已有的具体方法。如果需要这样做只能说明父类的方法不能作为具体方法而存在，将它改为抽象方法。
3.不在接口中定义属性
这是保全中的一个bug。为了使保全算功能便于扩展，定义了EdorAppConfirm接口：public interface EdorAppConfirm {
public CErrors mErrors = new CErrors();
public boolean submitData(VData cInputData, String cOperate);
public VData getResult();
}
然后再实现这个接口，比如：
public class GrpEdorNIAppConfirmBL implements EdorAppConfirm { public CErrors mErrors = new CErrors();
public boolean submitData(VData cInputData, String cOperate) { if (!dealData()) {
return false;
}
...
}
}
最后再调用这个接口：
Class tClass = Class.forName("com..lis.bq.GrpEdor" +
tEdorType + "AppConfirmBL");
EdorAppConfirm tGrpEdorAppConfirm = (EdorAppConfirm) tClass.newInstance();
VData tVData = new VData();
tVData.add(iLPGrpEdorItemSchema);
tVData.add(mLJSGetEndorseSchema);
tVData.add(mGlobalInput);
tVData.add(tLPGrpEdorMainSet);
if (!tGrpEdorAppConfirm.submitData(tVData,
"APPCONFIRM||" + tEdorType)) {
CError.buildErr(this, "保全项目" + tEdorType +
"试算时失败！失败原因：" + tGrpEdorAppConfirm.mErrors.
getFirstError());
return false;
}
这里本意是如果算费出错return false并返回错误原因，但实际上不可能得到错误原因。
因为EdorAppConfirm和GrpEdorNIAppConfirmBL中都定义了mErrors，此时返回的是接口中的mErrors。如果把GrpEdorNIAppConfirmBL中的mErrors去掉可以解决这个bug，但是在接口中定义public的属性不是好的做法，因此可考虑把mErrors换成getErrors方法。
4.接口和抽象类的组合使用
当我们准备使用抽象时会考虑是使用接口还使用抽象类，因为它们各有优缺点，接口和抽象类最大的区别是抽象类可以有具体实现而接口是纯抽象的。如果用抽象类那么写在抽象类中的具体实现代码的改动会导致各级子类的改动，如果使用接口避免了这个问题但又带来了另一个问题，就是各个实现接口的子类可能有重复的代码，如维护也需要维护多处地方。
因此比较好的方法是先定义一个接口，然后定义一个抽象类来实现这个接口，然后各个具体实现类继承这个抽象类，并把重复的实现代码放到抽象类中。这里要注意的是放到抽象类中的代码一定要是固定的，不会随需求改动的部分。
十、其它需注意地方
1.clone()的使用
java的clone机制使我们可以很方便的进行使用对象的复制，只需实现Cloneable接口就行了。如：
public class MyObject implements Cloneable {
public Object clone() {
try {
return super.clone();
} catch (CloneNotSupportedException e) {
throw new InternalError();
}
}
}
但要注意的是java分为深clone和浅clone，它们区别是对象内部的成员属性在clone 时是否处理为引用。如果仍然保留为引用，则称为浅clone，反之称为深clone。而java默认是浅clone，如果要实现深clone还需要对各个成员属性分别进行clone操作。
2.Javascript脚本的执行效率
IE执行脚本取object的length效率是很低的。不要在循环结构中的控制变量上直接使用“XX.length”，应避免如下程序段的写法：
var tFlag="";
for(i = 0; i if(fm.QueryType[i].checked){ tFlag=fm.QueryType[i].value; break; } } 应改为： countOfQueryType = fm.QueryType.length; for(i = 0; i 当例子中的QueryType对象数量超过15个以上时，操作用户会明显感到时间差异。 目前程序中存在比较多，且公共组件中亦存在。项目组最好派专人解决。 3.注意数据库连接的释放 Connection conn = DBConntPool.getConnection(); //建立数据库连接 try{ if (conn == null || conn.isClosed()) { conn = DBConnPool.getConnection(); } if (conn == null) { // @@错误处理 CError.buildErr(this, "数据库连接失败"); return false; } }catch(Exception e){} //在关闭连接的时候，同时将对象释放。 if( conn != null ) { conn.close(); conn = null; } 库连接与关闭的语句，最好写在同一个方法里，使程序易读性好，便于维护。举例： 浪费资源的代码： conn = DBConnPool.getConnection(); conn = DBConnPool.getConnection(); if (conn == null) { //return false; } tExeSQL = new ExeSQL(conn); 如果你发现程序中存在类似写法，请立即修改为： tExeSQL = new ExeSQL(); 代码审查报告 xxxx公司 版本信息 致？其余单词首字母大写的命名方式， 禁止使用下划线(_)数字等方式命名 不要出现局部变量，成员变量大写字母开头等问题 一般是否遵循了最小长度最多信息原则？各种命名尽可能短，表意准确，除2代替…to?，4代替…for?外，不建议使用数字在命名中 重要has/can/is前缀的函数是否返回布尔 型？ 成员变量，方法参数，局部变量等为布尔型时， 如果出现has/can/is开头，则将这些词去掉 重要类名是否存在重名问题？自己实现的类尽量不要和别人的类重名， 尽管不在同一个包下，特别是子类和父类重名的情况 注释 重要注释是否较清晰且必要？方法JAVADOC注释中需要说明各参数、返回值 及异常说明，参数说明需按照参数名称及用意对应标注 重要复杂的分支流程是否已经被注释？一般距离较远的}是否已经被注释？ 重要函数是否已经有文档注释？（功能、输 入、返回及其他可选） 文件，类（含接口，枚举等），成员变量， 方法前需要有JAVADOC的注释 一般特殊用法是否被注释？ 声 明、 空 白、 缩 进 一般每行是否只声明了一个变量？（特别是那些可能出错的类型） 重要变量是否已经在定义的同时初始化？ 重要类属性是否都执行了初始化？ 一般代码段落是否被合适地以空行分隔？ 一般是否合理地使用了空格使程序更清晰？基本代码格式中的空格符不可缺少， 这些空格出现在?,:,+,-,*,/,=,==,>,<,>=,<=,!=, 及各种括号附近 提示代码行长度是否在要求之内？每行不得超过120个字符 重要controller，service, dao 中不要声明有 状态的变量。 此变量不能被修改。如果要进行修改， 必须通过锁进行控制。 一般折行是否恰当？ 一般集合是否被定义为泛型类型？定义集合时，建议定义其泛型类型，减少类型转换和警告错误 语句/功能分布/规模 一般包含复合语句的{}是否成对出现并符合规范？ 重要是否给单个的循环、条件语句也加了 {}？ if,else,else if,while,for,case等 代码块必须用{}包围 一般单个变量是否只做单个用途？ 重要单行是否只有单个功能？（不要使用；进行多行合并） 重要单个函数是否执行了单个功能并与其命名相符？ 一般操作符＋＋和——操作符的应用是否符合规范？ 规模 重要单个函数不超过规定行数？ 重要缩进层数是否不超过规定？ 可靠 性 （总 PMD Eclipse-pmd插件下载： 网上给出的url都无法使用，可以去http://sourceforge.jp/projects/sfnet_pmd/releases/ 手动下载插件，解压后复制到eclipse的plugin和features目录下。重启eclipse后，windows —>preferences 下看到PMD选项则说明安装成功。 PMD使用： 1.检查代码 1）右键项目，PMD—>Check Code With PMD 2）在PMD视图下，可以看到检查结果。每个代码文件的违反规则的地方都被列出，右上角的五色圆形按钮，可以按照违规等级过滤列出的信息。从左到右依次为error high, error, warning high, warning, information。 3）在package explorer和代码文件中都会有标记 2.生成检查报告 1）检查后，右键项目，PMD—>Generate Reports。在项目目录下会生成reports文件夹，存 放检查报告。 3.清除违规标记 1）右键项目，PMD—>Clear PMD Violations 4.编辑检查规则 1）Window—>Preferences，左侧选择PMD—>Rules Configuration。 在Rules下已显示出PMD自带的检查规则。点击右侧Add rule 按钮，进入规则制定界面，如下所示。 检查规则在XPath项配置。 2)Window—>preferences—>PMD，点击Rule Designer，可以设计自己的规则。 输入Source Code和XPath Query，点击Go，可以查看PMD根据源代码生成的抽象语法数（AST）和匹配结果。 PS：想要熟练配置自己的规则，需要对XPath和PMD工作原理有一定的了解。可参考PMD 使用说明.doc中相关内容。 代码审查参考文档 代码审查（code review）是保证软件质量的一个重要环节，通过审查代码能够发觉代码中可能存在的问题并给予纠正，这些问题可能包括设计上的、实现上的或者编程风格等多方面。本文档通过列举代码编写过程中的一些常见的细节问题，为代码审查环节提供参考。 Java代码 一、对象和变量 1.存在未被使用的变量 Eclipse会自动用下划线标出 2.对象的重复创建 这是系统中普遍存在的问题，比如： public class PrtGrpEndorsementBL { private GlobalInput mGlobalInput = new GlobalInput(); private boolean getInputData(VData cInputData) { mGlobalInput = (GlobalInput) cInputData.getObjectByObjectName( "GlobalInput", 0); return true; } } 那个地点mGlobalInput对象属于重复创建，因为在getInputData方法里会对它进行赋值，mGlobalInput使用的应该是从jsp页面传入的对象，因此改为private GlobalInput mGlobalInput = null; 又如： String msg = ""; if (..) { msg = "A"; } else { msg = "B"; } 那个地点msg同样属于重复创建，改为String msg = null; 3.变量的作用域 Java的局部变量能够定义在函数的任何位置，有部分由c转学java的程序员适应将变量都定义在函数的顶部，因为在c 里只能那样定义。但实际上变量的作用域越短程序的内聚性就越高，耦合性也更低，程序更容易理解，因此在java里应该在使用前才定义变量。 4.局部变量的危害 定义过多的不必要的局部变量是造成系统难以维护的缘故之一，因为每增加一个局部变量我们就要先化时刻去理解那个局部变量的意思，因此我们要减少局部变量的使用。用函数的返回值来替代局部变量是一种有效的方法，这就需要我们用重构的方式从大的函数中提出小的函数，用小函数的返回值来替代原有的局部变量。把大函数分解本身也能够降低程序的耦合度。 静态代码检查工具Sonar的安装和使用 目录 静态代码检查工具Sonar的安装和使用 (1) 第一章、Sonar简介 (2) 第二章、Sonar原理 (3) 第三章、Sonarqube安装 (5) 3.1、下载安装包 (5) 3.2、数据库连接方式 (5) 3.3、启动 (7) 3.4、插件引用 (8) 第四章、SonarQube Scanner安装 (10) 4.1、下载安装 (10) 4.2、数据库连接方式 (12) 4.3、启动并执行代码检查 (13) 4.4、查看执行结果 (16) 4.5、启动失败原因 (18) 第一章、Sonar简介 Sonar (SonarQube)是一个开源平台，用于管理源代码的质量。Sonar 不只是一个质量数据报告工具，更是代码质量管理平台。支持的语言包括：Java、PHP、C#、C、Cobol、PL/SQL、Flex 等。 开源中国代码质量管理系统->https://www.doczj.com/doc/8316655411.html,/ 主要特点： ?代码覆盖：通过单元测试，将会显示哪行代码被选中 ?改善编码规则 ?搜寻编码规则：按照名字，插件，激活级别和类别进行查询 ?项目搜寻：按照项目的名字进行查询 ?对比数据：比较同一张表中的任何测量的趋势 第二章、Sonar原理 SonarQube 并不是简单地将各种质量检测工具的结果（例如FindBugs，PMD 等）直接展现给客户，而是通过不同的插件算法来对这些结果进行再加工，最终以量化的方式来衡量代码质量，从而方便地对不同规模和种类的工程进行相应的代码质量管理。 SonarQube 在进行代码质量管理时，会从图1 所示的七个纬度来分析项目的质量。 微软编码规范检查工具StyleCop 介绍 一.功能介绍 下载地址:\\10.15.3.7\外包解决方案中心\ITS交付中心\外包软件\Net\StyleCop-4.7.45.0 SourceAnalysis （StyleCop）不是代码格式化（代码美化）工具，而是代码规范检查工具（Code Review 工具），它不仅仅检查代码格式，而是编码规范，包括命名和注释等。 SourceAnalysis （StyleCop）目的是帮助项目团队执行一系列常用的源代码格式规范，这些规范是关于如何开发布局规整，易读，易维护并且文档良好的优雅代码的（help teams enforce a common set of best practices for layout, readability, maintainability, and documentation of C# source code）。 SourceAnalysis （StyleCop）现在包含了200 个左右的最佳实践规则（best practice rules），这些规则与Visual Studio 2005 和Visual Studio 2008 中默认的代码格式化规则是一致的。 SourceAnalysis （StyleCop）可以作为Visual studio 的插件运行. 同时SourceAnalysis （StyleCop）也可以作为MSBuild 任务（安装时有选项）通过命令行执行。 SourceAnalysis（StyleCop）是代码级别的，更适合于程序员在编程过程中使用。 SourceAnalysis（StyleCop）不提供灵活的规则设置，而是使用所谓one-size-fits-all 的方式强制人们用同样的习惯书写代码，因此SourceAnalysis （StyleCop）的终极目标是：The ultimate goal of Source Analysis is to allow you to produce elegant, consistent code that your team members and others who view your code will find highly readable. SourceAnalysis （StyleCop）检查的规则包括： ◆布局（Layout of elements, statements, expressions, and query clauses ） ◆括号位置（Placement of curly brackets, parenthesis, square brackets, etc ） ◆空格（Spacing around keywords and operator symbols ） ◆行距（Line spacing ） ◆参数位置（Placement of method parameters within method declarations or method calls ） ◆元素标准排列（Standard ordering of elements within a class ） ◆注释格式（Formatting of documentation within element headers and file headers ） ◆命名（Naming of elements, fields and variables ） ◆内置类型的使用（Use of the built-in types ） ◆访问修饰符的使用（Use of access modifiers ） ◆文件内容（Allowed contents of files ） ◆Debugging文本（Debugging text） 开始使用这些工具时可能会觉得对我们要求太苛刻，但根据微软自己的经验：after a short adjustment period, they came to appreciate the rules enforced by Source Analysis, and even began to find it difficult to read code not written in this style. Java静态检测工具的简单介绍- Sonar、Findbugs 2010-11-04 13:55:54 标签：sonar休闲职场 Java静态检测工具的简单介绍 from： https://www.doczj.com/doc/8316655411.html,/?p=9015静态检查:静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人 工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。 代码检查代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和 设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代 码结构的合理性等方面；可以发现违背程序编写标准的问题，程序中不安全、 不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题， 包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构 检查等内容。”。看了一系列的静态代码扫描或者叫静态代码分析工具后， 总结对工具的看法：静态代码扫描工具，和编译器的某些功能其实是很相似的， 他们也需要词法分析，语法分析，语意分析...但和编译器不一样的是他们可 以自定义各种各样的复杂的规则去对代码进行分析。 静态检测工具: 1.PMD 1)PMD是一个代码检查工具，它用于分析 Java 源代码，找出潜在的问题： 1)潜在的bug：空的try/catch/finally/switch语句 2)未使用的代码：未使用的局部变量、参数、私有方法等 3)可选的代码：String/StringBuffer的滥用 4)复杂的表达式：不必须的if语句、可以使用while循环完成的for循环 5)重复的代码：拷贝/粘贴代码意味着拷贝/粘贴bugs 2)PMD特点： 1)与其他分析工具不同的是，PMD通过静态分析获知代码错误。也就是说，在 不运行Java程序的情况下报告错误。 2)PMD附带了许多可以直接使用的规则，利用这些规则可以找出Java源程序的许 多问题 3)用户还可以自己定义规则，检查Java代码是否符合某些特定的编码规范。 3)同时，PMD已经与JDeveloper、Eclipse、jEdit、JBuilder、BlueJ、 CodeGuide、NetBeans、Sun JavaStudio Enterprise/Creator、 IntelliJ IDEA、TextPad、Maven、Ant、Gel、JCreator以及Emacs 集成在一起。 4)PMD规则是可以定制的: 可用的规则并不仅限于内置规则。您可以添加新规则： 可以通过编写 Java 代码并重新编译 PDM，或者更简单些，编写 XPath 表 达式，它会针对每个 Java 类的抽象语法树进行处理。 5)只使用PDM内置规则，PMD 也可以找到你代码中的一些真正问题。某些问题可能 很小，但有些问题则可能很大。PMD 不可能找到每个 bug，你仍然需要做单元测 试和接受测试，在查找已知 bug 时，即使是 PMD 也无法替代一个好的调试器。 简介 本文首先介绍了静态代码分析的基本概念及主要技术，随后分别介绍了现有4 种主流Java 静态代码分析工具(Checkstyle，FindBugs，PMD，Jtest)，最后从功能、特性等方面对它们进行分析和比较，希望能够帮助Java 软件开发人员了解静态代码分析工具，并选择合适的工具应用到软件开发中。 引言 在Java 软件开发过程中，开发团队往往要花费大量的时间和精力发现并修改代码缺陷。Java 静态代码分析（static code analysis）工具能够在代码构建过程中帮助开发人员快速、有效的定位代码缺陷并及时纠正这些问题，从而极大地提高软件可靠性并节省软件开发和测试成本。目前市场上的Java 静态代码分析工具种类繁多且各有千秋，因此本文将分别介绍现有4 种主流Java 静态代码分析工具(Checkstyle，FindBugs，PMD，Jtest)，并从功能、特性等方面对它们进行分析和比较，希望能够帮助Java 软件开发人员了解静态代码分析工具，并选择合适的工具应用到软件开发中。 静态代码分析工具简介 什么是静态代码分析 静态代码分析是指无需运行被测代码，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，找出代码隐藏的错误和缺陷，如参数不匹配，有歧义的嵌套语句，错误的递归，非法计算，可能出现的空指针引用等等。 在软件开发过程中，静态代码分析往往先于动态测试之前进行，同时也可以作为制定动态测试用例的参考。统计证明，在整个软件开发生命周期中，30% 至70% 的代码逻辑设计和编码缺陷是可以通过静态代码分析来发现和修复的。 但是，由于静态代码分析往往要求大量的时间消耗和相关知识的积累，因此对于软件开发团队来说，使用静态代码分析工具自动化执行代码检查和分析，能够极大地提高软件可靠性并节省软件开发和测试成本。 静态代码分析工具的优势 1. 帮助程序开发人员自动执行静态代码分析，快速定位代码隐藏错误和缺陷。 2. 帮助代码设计人员更专注于分析和解决代码设计缺陷。 3. 显著减少在代码逐行检查上花费的时间，提高软件可靠性并节省软件开发和测试成本。 源代码安全要靠谁？ 段晨晖2010-03-04 三款静态源代码安全检测工具比较 1. 概述 随着网络的飞速发展，各种网络应用不断成熟，各种开发技术层出不穷，上网已经成为人们日常生活中的一个重要组成部分。在享受互联网带来的各种方便之处的同时，安全问题也变得越来越重要。黑客、病毒、木马等不断攻击着各种网站，如何保证网站的安全成为一个非常热门的话题。 根据IT研究与顾问咨询公司Gartner统计数据显示，75%的黑客攻击发生在应用层。而由NIST的统计显示92%的漏洞属于应用层而非网络层。因此，应用软件的自身的安全问题是我们信息安全领域最为关心的问题，也是我们面临的一个新的领域，需要我们所有的在应用软件开发和管理的各个层面的成员共同的努力来完成。越来越多的安全产品厂商也已经在考虑关注软件开发的整个流程，将安全检测与监测融入需求分析、概要设计、详细设计、编码、测试等各个阶段以全面的保证应用安全。 对于应用安全性的检测目前大多数是通过测试的方式来实现。测试大体上分为黑盒测试和白盒测试两种。黑盒测试一般使用的是渗透的方法，这种方法仍然带有明显的黑盒测试本身的不足，需要大量的测试用例来进行覆盖，且测试完成后仍无法保证软件是否仍然存在风险。现在白盒测试中源代码扫描越来越成为一种流行的技术，使用源代码扫描产品对软件进行代码扫描，一方面可以找出潜在的风险，从内对软件进行检测，提高代码的安全性，另一方面也可以进一步提高代码的质量。黑盒的渗透测试和白盒的源代码扫描内外结合，可以使得软件的安全性得到很大程度的提高。 源代码分析技术由来已久，Colorado 大学的 Lloyd D. Fosdick 和 Leon J. Osterweil 1976 年的 9 月曾在 ACM Computing Surveys 上发表了著名的 Data Flow Analysis in Software Reliability，其中就提到了数据流分析、状态机系统、边界检测、数据类型验证、控制流分析等技术。随着计算机语言的不断演进，源代码分析的技术也在日趋完善，在不同的细分领域，出现了很多不错的源代码分析产品，如 Klocwork Insight、Rational Software Analyzer 和 Coverity、Parasoft 等公司的产品。而在静态源代码安全分析方面，Fortify 公司和 Ounce Labs 公司的静态代码分析器都是非常不错的产品。对于源代码安全检测领域目前的供应商有很多，这里我们选择其中的三款具有代表性的进行对比，分别是Fortify公司的Fortify SCA，Security Innovation公司的Checkmarx Suite和Armorize 公司的CodeSecure。 2. 工具介绍 静态检查:静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。 代码检查代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和 设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代 码结构的合理性等方面；可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构 检查等内容。”。看了一系列的静态代码扫描或者叫静态代码分析工具后， 总结对工具的看法：静态代码扫描工具，和编译器的某些功能其实是很相似的，他们也需要词法分析，语法分析，语意分析...但和编译器不一样的是他们可 以自定义各种各样的复杂的规则去对代码进行分析。 静态检测工具: 1. PMD 1)PMD是一个代码检查工具，它用于分析 Java 源代码，找出潜在的问题： 1)潜在的bug：空的try/catch/finally/switch语句 2)未使用的代码：未使用的局部变量、参数、私有方法等 3)可选的代码：String/StringBuffer的滥用 4)复杂的表达式：不必须的if语句、可以使用while循环完成的for循环 5)重复的代码：拷贝/粘贴代码意味着拷贝/粘贴bugs 2)PMD特点： 1)与其他分析工具不同的是，PMD通过静态分析获知代码错误。也就是说，在 不运行Java程序的情况下报告错误。 2)PMD附带了许多可以直接使用的规则，利用这些规则可以找出Java源程序的许 多问题 3)用户还可以自己定义规则，检查Java代码是否符合某些特定的编码规范。 3)同时，PMD已经与JDeveloper、Eclipse、jEdit、JBuilder、BlueJ、 CodeGuide、NetBeans、Sun JavaStudio Enterprise/Creator、 IntelliJ IDEA、TextPad、Maven、Ant、Gel、JCreator以及Emacs 集成在一起。 4)PMD规则是可以定制的: 可用的规则并不仅限于内置规则。您可以添加新规则： 可以通过编写 Java 代码并重新编译 PDM，或者更简单些，编写 XPath 表 达式，它会针对每个 Java 类的抽象语法树进行处理。 5)只使用PDM内置规则，PMD 也可以找到你代码中的一些真正问题。某些问题可能 很小，但有些问题则可能很大。PMD 不可能找到每个 bug，你仍然需要做单元测试和接受测试，在查找已知 bug 时，即使是 PMD 也无法替代一个好的调试器。 但是，PMD 确实可以帮助你发现未知的问题。 1. FindBugs 1)FindBugs是一个开源的静态代码分析工具，基于LGPL开源协议，无需 运行就能对代码进行分析的工具。不注重style及format，注重检测真正 信息安全 等级保护检查工具箱系统 技术白皮书 国家信息技术安全研究中心 版权声明 本技术白皮书是国家信息技术安全研究中心研制的信息系统安全等级保护 检查工具箱产品的描述。与内容相关的权利归国家信息技术安全研究中心所有。白皮书中的任何内容未经本中心许可，不得转印、复制。 联系方式： 国家信息技术安全研究中心 地址：北京市海淀区农大南路1号硅谷亮城 2号楼C座4层 电话:0 简介 国家信息技术安全研究中心（以下简称，中心）是适应国家信息安全保障需要批准组建的国家级科研机构，是从事信息安全核心技术研究、为国家信息安全保障服务的事业单位。 中心成立于2005年，是国家有关部门明确的信息安全风险评估专控队伍、等级保护测评单位、国家网络与信息安全应急响应技术支撑团队和国家电子政务非保密项目信息安全专业测评机构。 中心通过系统安全性检测、产品安全性检测、信息安全技术支持、信息安全理论研究、远程监控服务等项目，为国家基础信息网络和重要信息系统及社会各界提供多种形式的信息安全技术服务。 为提高我国基础信息网络和重要信息系统的安全防护水平，中心自主研发了一系列安全防护和检测工具产品。主要有：恶意代码综合监控系统、信息系统等级保护检查/测评工具箱、安全内网管控系统、网上银行安全控件、系统安全检测工具集、网络数据流安全监测系统、商品密码安全性检测工具集、漏洞扫描评估系统等。 中心还积极承担国家“863”、国家发改委专项和密码发展基金等国家重点科研项目；积极承担国家下达的多项信息安全标准制定和研究任务；紧密跟踪国内外信息安全发展，采取多种形式为国家有关部门和行业提供信息安全咨询和培训服务。 经过多年的发展，中心服务的足迹遍及30余个省市自治区，为政府机关、电信、电力、金融、海关、铁路、广电、税务等行业部门的数百个单位、上千个重要信息系统提供了信息安全产品、咨询和测评服务。 XX系统源代码安全审计报告 XX部门 20XX年X月 目录 1.源代码审计概述 (1) 1.1.审计对象 (1) 1.2.审计目的 (1) 1.3.审计流程 (1) 1.4.审计组织 (1) 2.源代码审计范围 (1) 3.源代码审计详情 (1) 3.1.安全风险定义 (1) 3.2.安全缺陷统计 (2) 3.3.安全缺陷示例 (2) 3.3.1.隐私泄露 (3) 3.3.2.跨站脚本漏洞 (3) 3.3.3.SQL注入缺陷 (3) 3.3.4.XXX缺陷 (3) 4.总结 (3) 1.源代码审计概述 1.1.审计对象 描述本文档适用范围、场景等相关的背景情况，便于读者充分了解审计对象信息。1.2.审计目的 描述开展源代码审计工作的目的、依据、要求以及预期效果。 1.3.审计流程 描述源代码代码审计工作的流程，包括但不限于测试环境的搭建、测试方法或模式（例如工具测试、人工检查）、审计报告及整改方案的撰写，并明确各项工作的相关职责方。1.4.审计组织 描述开展代码审计工作组织情况，包括但不限于安全保密以及审计工作准备情况。2.源代码审计范围 描述被审计系统情况，包括但不限于源代码行数、源代码文件大小、设计语言及组件、开发软件环境、系统架构、编译器、系统类库、系统服务器及数据库等信息。 3.源代码审计详情 3.1.安全风险定义 源代码安全审计是运用工具和人工分析对源代码进行检查，检查系统软件存在的安全缺陷。根据安全缺陷可能存在的安全风险对检查中发现的各个缺陷给出了相对应的风险评价，并对风险评价中涉及到的各个等级给予一定说明和界定，如风险级别高、中、低并依次描述各级别对应威胁，示例如下： 一. 概述 1.1 源代码审计概述 源代码审计工作通过分析当前应用系统的源代码，熟悉业务系统，从应用系统结构方面检查其各模块和功能之间的关联、权限验证等内容；从安全性方面检查其脆弱性和缺陷。在明确当前安全现状和需求的情况下，对下一步的编码安全规范性建设有重大的意义。 源代码审计工作利用一定的编程规范和标准，针对应用程序源代码，从结构、脆弱性以及缺陷等方面进行审查，以发现当前应用程序中存在的安全缺陷以及代码的规范性缺陷。 审核目的 本次源代码审计工作是通过对当前系统各模块的源代码进行审查，以检查代码在程序编写上可能引起的安全性和脆弱性问题。 审核依据 本次源代码审计工作主要突出代码编写的缺陷和脆弱性，以OWASP TOP 10 2010为检查依据，针对OWASP统计的问题作重点检查。 点击打开文档OWASP TOP 10 2010 审计范围 根据XX给出的代码，对其WEB应用作脆弱性和缺陷、以及结构上的检查。通过了解业务系统，确定重点检查模块以及重要文件，提供可行性的解决方法。 审计方法 通过白盒（代码审计）的方式检查应用系统的安全性，白盒测试所采用的方法是工具审查+人工确认+人工抽取代码检查，依照OWASP 2010 TOP 10所披露的脆弱性，根据业务流来检查目标系统的脆弱性、缺陷以及结构上的问题。 本次源代码审计分为三个阶段： 信息收集 此阶段中，源代码审计人员熟悉待审计WEB应用的结构设计、功能模块，并与客户相关人员商议、协调审计重点及源代码提供等方面的信息。 代码安全性分析 此阶段中，源代码审计人员会使用工具对源代码的脆弱性和安全缺陷进行初步的分析，然后根据客户关注的重点对部分代码进行手工审计，主要包含以下内容： 输入/输出验证。SQL注入、跨站脚本、拒绝服务攻击，对上传文件的控制等因为未能较好的控制用户提交的内容造成的问题； 安全功能。请求的参数没有限制范围导致信息泄露，Cookie超时机制和有效域控制，权限控制、日志审计等方面的内容； 程序异常处理。忽略处理的异常、异常处理不恰当造成的信息泄露或是不便于进行错误定位等问题； 代码规范性检查 此阶段中，源代码审计人员主要是利用一些代码规范检查工具对网站各功能模块的代码进行合规性检查，主要目的在于提高代码质量，使其更符合编码规范的要求，主要包括以下内容： 代码质量。例如对象错误或不适合调用导致程序未能按预期的方式执行，功能缺失；类成员与其封装类同名，变量赋值后不使用等； 封装。多余的注释信息、调试信息问题导致应用系统信息暴露，错误的变量声明等。 API滥用。例如调用非本单位直接控制的资源、对象过于频繁调用、直接调用空对象导致系统资源消耗过大或是程序执行效率低下等问题。 软件著作权申报中60页标准代码文档的写作经验谈 在申报著作权的工作中，都要提供软件的60页源代码。这是一种特殊要求的东西，它 要求每页50行程序，并要求前30页是程序的前半部分有开头并连续，后30页是程序的后半部分包括结尾也要连续，30和31页之间可以不连续。这个文档的格式，一般要求有页眉 上标记申报的软件名称，天津还要有行标，页眉的右边有，第某页，共60页字样。 这样的要求通常负责技术的开发人员，是没有时间和精力做好后，提供给申报人员的， 这就需要负责申报的人员，根据技术开发人员提供的源代码进行编辑，使之符合申报的要求。对此，我曾经反复按照这个要求去处理技术人员传来的代码，一开始确实破费周折，处理的多了也慢慢总结出一些经验来，在这里与系统内负责申报的同仁分享。 一、程序的选择 要选择超过3000行的源代码，这样才能裁剪出，符合要求的代码，同时，最好选取核 心程序的代码，这样"using ”等语句会对应主数据库或主要的模块。程序要有比较鲜明的 开始段落和结尾的段落，还注意去掉一些注释性的内容，如下面这样的部分。 #region 统计导出XLS模板 /****************************************************************** * 城信所国土房产政务平台Copyright (c) 2011-2015 Inc. * ALL RIGHTS RESERVED *功能描述：统计导出XLS模板 *作者： *创建日期：2011-11-28 *版本： *更新说明： * **************************************************************/ #en dregi on 测试工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具，另外还有用于测试管理（测试流程管理、缺陷跟踪管理、测试用例管理）的工具，这些产品主要是MercuryInteractive （MI）、Segue、IBM Rational、Compuware和Empirix等公司的产品，而MI公司的产品占了主流。 白盒测试工具 白盒测试工具一般是针对代码进行测试，测试中发现的缺陷可以定位到代码级，根据测试工具原理的不同，又可以分为静态测试工具和动态测试工具。 静态测试工具：直接对代码进行分析，不需要运行代码，也不需要对代码编译链接，生成可执行文件。静态测试工具一般是对代码进行语法扫描，找出不符合编码规范的地方，根据某种质量模型评价代码的质量，生成系统的调用关系图等。静态测试工具的代表有：Telelogic 公司的Logiscope软件；PR公司的PRQA软件。 动态测试工具：动态测试工具与静态测试工具不同，动态测试工具的一般采用"插桩"的方式，向代码生成的可执行文件中插入一些监测代码，用来统计程序运行时的数据。其与静态测试工具最大的不同就是动态测试工具要求被测系统实际运行。动态测试工具的代表有：Compuware公司的DevPartner软件；Rational公司的Purify系列等。 黑盒测试工具 黑盒测试工具适用于黑盒测试的场合，黑盒测试工具包括功能测试工具和性能测试工具。黑盒测试工具的一般原理是利用脚本的录制(Record)/回放(Playback)，模拟用户的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。黑盒测试工具可以大大减轻黑盒测试的工作量，在迭代开发的过程中，能够很好地进行回归测试。黑盒测试工具的代表有：Rational公司的TeamTest、Robot；Compuware公司的QACenter。 性能测试工具 专用于性能测试的工具包括有：Radview公司的WebLoad；Microsoft公司的WebStress 等工具；针对数据库测试的TestBytes；对应用性能进行优化的EcoScope等工具。MercuryInteractive的LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。 测试管理工具 测试管理工具用于对测试进行管理。一般而言，测试管理工具对测试计划、测试用例、测试实施进行管理，并且，测试管理工具还包括对缺陷的跟踪管理。测试管理工具的代表有：Rational公司的Test Manager；Compureware公司的TrackRecord；Mercury Interactive公司的TestDirector等软件。一般而言，测试管理工具对测试需求、测试计划、测试用例、测试实施进行管理，并且测试管理工具还包括对缺陷的跟踪管理。测试管理工具能让测试人员、开发人员或其他的IT人员通过一个中央数据仓库，在不同地方就能交互信息。 代码审核的政策及标准要求 根据IT研究与顾问咨询公司Gartner统计数据显示，75%的黑客攻击发生在应用层。而由NIST的统计显示92%的漏洞属于应用层而非网络层。因此，应用软件的自身的安全问题是我们信息安全领域最为关心的问题。鉴于信息安全发展中所面临的软件安全问题，各个标准化组织及相关管理部门分别从法规、信息安全管理体系建设及行业安全标准等角度对软件进行规范，对软件安全的代码审查工作提出了相应的要求。 1、《信息安全等级保护基本要求》 根据《基本要求》中关于外包软件开发的相关要求，一级要求开始就对外包开发软件在上线前进行恶意代码检测，“应在软件安装之前检测软件包中可能存在的恶意代码”。在测试验收中，提出了对系统进行安全性测试，“应对系统进行安全性测试验收”。在二级要求中，增加了对源代码进行后门检查的要求，“应要求开发单位提供软件源代码，并审查软件中可能存在的后门”。三级要求中明确指出要求由第三方测试单位实施系统安全性测试，“应委托公正的第三方测试单位对系统进行安全性测试，并出具安全性测试报告”。四级要求中增加了对源代码隐蔽信道的安全检查要求， 从《基本要求》关于系统安全性测试要求的变化可以看出，系统安全性测试强度不断提高，在四级要求中增加了对“隐蔽信道”的安全检查，测试机构从无要求转向了三级要求中明确规定的第三方测试单位。一级要求中的恶意代码检测和安全性测试，未明确要求进行源代码层面的安全测试，《基本要求》要求在测试验收时进行必要的软件安全性测试，代码审查可以作为软件安全性测试一项其重要手段，但未进行明确的规定。在二级要求中增加了对源代码进行后门检查及四级要求中对源代码进行隐蔽信道检查，提供了源代码检测的必要依据。 2、萨班斯法案 尽管萨班斯法案没有提及IT或者信息安全，但对绝大多数现代企业来说，财务报告无可避免地会与信息技术联系在一起；换句话说，如果某些关键系统失效了，企业正确报告其财务状况的能力就可能严重受限，甚至短期内丧失。在第404节管理层对内部控制的评价中，强调了管理层对内部控制的系统的责任，在IT审计过程中，审计师必须评估IT控制的设计效力，确定其是否为实现相关声 代码审查(Code Review) 一、概述 代码审查（Code Review)是软件开发中常用的手段，和QA测试相比，它更容易发现和架构以及时序相关等较难发现的问题，还可以帮助团队成员提高编程技能，统一编程风格等，目前监控团队虽然提倡代码审查，也有相关的辅助工具，但是一直没有真正的推行起来，这半年的时间里，一些线上的bug如果经过代码审查，基本上可以避免的，大家也逐渐认识到代码审查可以有效地提高代码质量。 二、代码审查的作用 1、提高代码质量。 通过代码审查来发现bug及代码中的不规范，这是不容置疑的，通过代码审查，代码将更加整洁，有更好的注释，更好的程序结构。 2、提高开发者开发水平。 开发者知道自己编写的代码会被同事审查，将会更加认真的编写代码，也将会督促开者不断地学习、向有经验的同事请教。 3、提高程序的可维护性。 一份程序代码将会有更多的同事熟悉，更好的代码质量，自 然地也增加程序的可维护性。 4、提高开发者的对编码的责任感。 如果你在编程，而且知道将会有同事检查你的代码，你编程态度就完全不一样了。你写出的代码将更加整洁，有更好的注释，更好的程序结构——因为你知道，那个你很在意的人将会查看你的程序。没有代码审查，你知道人们最终还是会看你的程序。但这种事情不是立即发生的事，它不会给你带来同等的紧迫感，它不会给你相同的个人评判的那种感受。 5、传播知识 在很多的开发团队里，经常每一个人负责一个核心模块，每个人都只关注他自己的那个模块。除非是同事的模块影响了自己的程序，他们从不相互交流。这种情况的后果是，每个模块只有一个人熟悉里面的代码。如果这个人休假或——但愿不是——辞职了，其他人则束手无策。通过代码审查，至少会有两个人熟悉这些程序——作者，以及审查者。审查者并不能像程序的作者一样对程序十分了解——但他会熟悉程序的设计和架构，这是极其重要的。 三、代码审查的执行障碍 1、缺少代码审查的标准 缺少代码审查的标准，往往审查人员习惯性地根据自身开发经验去进行代码审查，容易变成去挑毛病，找bug，容易产生 C语言编程准则检查工具C Checker 1概述 C语言编程准则检查工具C Checker是由航天软件评测中心自主研发的、基于C语言开发环境、用于对C语言编写的程序进行准则检查及安全性分析的软件工具。 C Checker可以为高可靠高安全软件的开发提供有力支持，它面向三个层次的用户，包括开发人员、软件质量管理人员与测试人员，帮助他们发现软件编程方面的安全隐患，避免一些不良的编码风格，从而提高代码的可读性与编程水平，降低出错概率，改进代码质量。 2功能 C Checker当前版本为1.0，支持GCC、CCS、TC等多种开发环境开发的C程序，检查内容及给出的结果符合GJB5369-2005（C语言安全子集）、Q/WE905-2005标准。 C Checker的主要功能包括 1．检查C语言源代码的安全缺陷 2．检查程序的注释度（可读性） 3．按一定的编写风格美化源代码程序 4．自动生成检查结果报告 3特性 C Checker基于先进编译技术、静态编码安全性程序分析技术、基于契约的自下而上分析方法、语言特征信息识别扩展机制等先进技术，经过多个航天项目实际使用验证，确保了准则检查的精确性，为航天型号软件质量保障提供了有力支持。 C Checker针对声明后没有使用、类型不一致、先使用后定义、不可达的代码、忽略返回值、执行路径没有返回、可能的死循环、缓冲区溢出问题和动态内存错误，以及使用了不安全的C库函数等方面，提出安全警示；同时，还能够对软件进行度量，对软件的安全性和可靠性给予指示。 C Checker界面与Visual Studio风格相似，界面友好，易学易用。 图1C Checker运行界面 C Checker根据C语言编程准则（Misra准则、GJB5369-2005航天型号软件C语言安全子集、Q/WE905-2005），所检查的编程准则类型包括声明定义类、分支控制类、指针使用类、跳转控制类等。用户可以通过设置扫描类型方便地对检查准则进行剪裁。 图2设置扫描类型 C Checker生成HTML格式的检测结果报告，警示信息直接标注于代码行下方，清晰直 观，方便查看。 Sonarqube简介 Sonarqube是一个用于代码质量管理的开源平台，用于管理源代码的质量。在我们的Sonarqube服务器系统中，规则分为Findbugs, PMD,Checkstyle, SonarQube, Find Security Bugs, PMD Unit Tests和Common SonarQube，其中各个规则占得比例如下图所示： 其中，Findbugs，PMD和CheckStyle的严重等级的规则大部分可以通过插件的形式集成到eclipse里，占全部规则的73.7%。其中，eclipse插件中集成的严重等级规则条数及其所占比例如下图所示： 1.Findbugs简介 FindBugs是一个静态代码分析工具，它检查类或者JAR 文件，将字节码与一组缺陷模式进行对比以发现可能的问题。有了静态分析工具，就可以在不实际运行程序的情况下，对软件进行分析。 在FindBugs的GUI中，需要先选择待扫描的class文件，FindBugs其实就是对编译后的class进行扫描，藉以发现一些隐藏的bug。如果你拥有这些class对应的源文件，可把这些java文件再选上，这样便可以从稍后得出的报告中快捷的定位到出问题的代码上面。此外，还可以选上工程所使用的library，这样似乎可以帮助FindBugs做一些高阶的检查，藉以发现一些更深层的bug。 选定了以上各项后，便可以开始检测了。检测的过程可能会花好几分钟，具体视工程的规模而定。检测完毕可生成一份详细的报告，藉由这份报告，可以发现许多代码中间潜在的bug。比较典型的，如引用了空指针(null pointer dereference), 特定的资源(db connection)未关闭，等等。如果用人工检查的方式，这些bug可能很难才会被发现，或许永远也无法发现，直到运行时发作。当除掉了这些典型的(classic) bug后，可以确信的是，我们的系统稳定度将会上一个新的台阶。 2.PMD简介 PMD是一种开源分析Java代码错误的工具。与其他分析工具不同的是，PMD通过静态分析获知代码错误。也就是说，在不运行Java程序的情况下报告错误。PMD附带代码审计报告3
PMD代码分析工具使用报告
代码审查参考文件
静态代码检查工具Sonar的安装和使用
微软编码规范检查工具StyleCop_介绍
Java静态检测工具的简单介绍 - Sonar、Findbugs
4种代码扫描工具分析
三款静态源代码安全检测工具比较
java代码静态检查工具介绍
信息安全等级保护检查工具箱技术白皮书
系统源代码安全审计报告(模板)
代码审计报告
软件著作权申报中60页标准代码文档的写作经验谈
软件测试工具分类
代码审查的政策及标准要求
代码审查(Code Review)
C语言规则检查工具C CHECKER
静态代码检查简介
相关主题
文本预览