Java Code review一些原则的原因探讨，下面这些原则都是为什么

Question

原文
http://blog.csdn.net/wzwdcld/article/details/48241961

Java Code Review清单

下面列出自己不理解的部分和大家探讨^-^
下面每一条都是不理解的，想知道这样做的动机是什么。。

整洁性

清单项目	分类
确定应用了代码格式化	格式
使用异常而不是返回码	异常
不要返回Null	异常

安全

清单项目	分类	备注
避免对于一些不寻常行为的过分日志	拒绝服务(Denial of Service)
在任何情况下都释放资源(流，连接等等)	拒绝服务(Denial of Service)
把从不可信对象得到的输出作为输入来检验	输入检验(Input Validation)
为native方法定义包装类(而不是定义native方法为pulibc)	输入检验(Input Validation)	什么是native方法
使public static域为final(避免调用方(caller)修改它的值)	可变性	caller是什么
小心地缓存潜在的特权操作结果	序列化反序列化(Serialization Deserialization)
只有在需要的时候才使用JNI	访问限制

清单项目	分类	备注
更多地使用标准异常	异常
避免使用finalizer	创建和销毁对象
使用枚举来代替int常量	枚举和注解(Annotations)
使用executors而不是task和thread	并发
查看静态代码分析器的报告来进行类的添加和修改	静态代码分析	静态代码分析器是什么东西

JBehave是干嘛的？

Answer 1

静态分析器是什么
这个是指使用静态代码检查工具去检查源码，你不需要运行单元测试代码，就可以发现代码中潜在的问题，通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，找出代码隐藏的错误和缺陷，如参数不匹配，有歧义的嵌套语句，错误的递归，非法计算，可能出现的空指针引用等等。
Java中常见的工具有Findbugs，CheckStyle，PMD等，这些工具通常都有Eclipse, Intellij Idea插件，开发人员在开发的时候可以很方便的运行，从而尽早发现问题，在代码Checkin之前就可以解决问题。这些工具也可以和Jenkins等自动化构建工具集成，在发布的时候给予运维人员参考。

Answer 2

感谢邀请，不过 Java 丢得有点久了，仅供参考

什么是 native 方法？

native 方法大概是指用 C/C++ 或其它直接编译成指令的那些方法，通常是生成 .dll(windows) 或 .so(linux)，再由 Java 通过 JNI 调用的

caller 是什么？

一般来说 caller 是指方法的调用者，域应该是 field 的翻译，但翻译成“字段”更容易解理。比如

public class A { ... }

public class B {
    public static A a;
    // 本条推荐改为如下，并在 static 块中初始化
    // public static final A a;
}

public class C {
    // 这个就是 caller
    public void doSomething() {
        // 不管有意无意，这里是把值给改了
        B.a = new A();
        // 但如果在 B 里把 a 定义成 final 的，上句就会编译错误
    }
}

而有了 bean 规范之后，这种字段通常会定义为 private，再加 setter 或 getter。

静态分析器是什么

静态分析器是指比编译器更严格的一个类似编译器的东西，从源代码直接分析出来有可能发生的逻辑错误。关于静态分析工具，可以找度娘问。我用过 FindBugs，还是有些作用，编程习惯不是很好的人，写出来的代码会有很多警告。

解释

整洁性

1. 确定应用了代码格式化

   代码格式整洁，才易于阅读，最典型的就是缩进规则
   

2. 使用异常而不是返回码

   异常和返回码是两种错误传递方式，异常的特点是立即中断跳出直到被 catch 住，返回码的特点是通过 return 返回一个错误代码。由于OOP的思想，要求方法尽可能简单，所以经常会存在我层级调用的情况，如果用异常，可以只在顶层处理异常，中途发生的任何异常都可以直接中断操作跳出来。但是如果用返回码，得一层层检查，代码繁琐，不易阅读。另外一点，Java的非 `RuntimeException` 必须在代码中申明处理（`catch` 或 `throws`），这样在编译阶段就能够进行一些逻辑异常处理的检查。
   
   但个人对这个持保留态度，看情况而定，少量使用返回码也不是不可以的。
   

3. 不要返回Null

   不返回 `null` 主要是为了避免繁琐的判空操作，尤其是对集合类型的处理，除了判空(null) 还要判空(empty)。所以约定返回值都不为空，而是返回默认值，可以减少部分判断代码，也尽可能的避免了 `NullPointerException`。
   
   C# 为了这个 null 的问题，扩展了很多语法和库，比如 `string.IsNullOrEmpty`，`??` 运算符以及 C#6.0 的空值条件运算符 `?.` 都是为了解决空问题而生的。
   
   同样持保留态度。目前用得最多的只是返回集合不为 `null`，避免在 `foreach` 之前还要先判断。其它的视情况而定。
   

安全

1. 避免对于一些不寻常行为的过分日志

   日志操作也是要消耗资源的，日志操作越多越耗资源，所以看着办吧。
   

2. 在任何情况下都释放资源(流，连接等等)

   避免资源耗尽（诸如内存泄漏等）
   

3. 把从不可信对象得到的输出作为输入来检验

   保证数据有效性
   

4. 为native方法定义包装类(而不是定义native方法为pulibc)

   看看设计模式中的适配器，桥接和外观模式等
   

5. 使public static域为final(避免调用方(caller)修改它的值)

   这个上面已经说了
   

6. 小心地缓存潜在的特权操作结果

   不是很懂，不过缓存本身是需要小心使用的，因为缓存具有不持久性。另外，缓存的有效期和授权的有效期不一致可能造成安全问题。
   

7. 只有在需要的时候才使用JNI

清单项目

1. 更多地使用标准异常

   标准异常基本上已经够用了。但适当的加入自己的异常类有助于代码流程管理。
   

2. 避免使用finalizer

   因为不确定什么时候会调用
   

3. 使用枚举来代替int常量

   枚举值限定，int 无法限定
   

4. 使用executors而不是task和thread

   大概是因为 Task 和 Thread 比较重吧。Java 的我不太了解，C# 的 Task 是轻量线程，所以轻量任务会使用 Task 代替 Thread。不过如果线程控制得好，对于重型任务使用 Thread 那是必须的。
   

5. 查看静态代码分析器的报告来进行类的添加和修改

   更严格的检查，仅供参考。如果机器都能准确的分析出所有错误，那也不需要人写程序了。个人认为对高级程序员用处不大，但用于团队中代码检查和习惯养成还是很有用的。