原链接：
MIT Software Construction Reading 4: Code Review
简单来说，代码评审就是由不是写代码的人来对代码进行仔细、系统的检查
代码评审有助于发现程序中的bug，规范代码，但更重要的是，这是程序员之间相互交流、学习的良好途径
比如说在Google，必须有人为你的代码进行评审并签字，你才能将其推送到总仓库里
代码评审（包括自己写代码）时的一些原则：
DRY（Don’t Repeat Yourself）
不要出现重复的或十分相似的代码
因此，Ctrl + C， Ctrl + V 实际上是有很大风险的
因为你很可能在日后发现问题时，修改了一处代码，而漏掉了另一处
好好写注释
对于java而言，最常见的注释就是类和方法前的specification，比如
/**
* Compute the hailstone sequence.
* See http://en.wikipedia.org/wiki/Collatz_conjecture#Statement_of_the_problem
* @param n starting number of sequence; requires n > 0.
* @return the hailstone sequence starting at n and ending with 1.
* For example, hailstone(3)=[3,10,5,16,8,4,2,1].
*/
public static List<Integer> hailstoneSequence(int n) {
...
}注释是和别人交流的方式（包括未来的自己），如果没有注释，时间久了你很可能看不懂你自己的代码，也可能在与他人共同合作时埋下隐患，比如，你的循环是从0到n-1呢，还是 1到n呢
发现问题时尽快做出反应
如果某个方法传入了不合规的参数，我们应该让程序尽快结束，停止执行，抛出异常，或其它，而不是安安静静的让程序带着这个潜在的隐患继续执行
代码中要尽量避免“奇怪的数”
要尽量避免除了0，1（或者加上2）以外的数
比如定义了一个数组int a[100]
那么问题来了，为什么是100？
再比如，用1~12来表示月份并不是很妥当，更好的方法是定义一个枚举类型，这样能增强代码的可读性
一个变量只用于一个目的
一个变量的名字往往说明了它的作用，我们就不应该为了“节约”，而将它用于不是它本职工作的地方
因为变量其实不是一种稀缺资源，如果一个变量完成了它的使命，那么就不要再将它用于其它地方，否则的话会对读代码的人造成困惑（变量没有用于它名字所说明的地方）
不要对传入的参数进行修改
对于一个方法，传入的参数被修改的话，以后再次需要它的信息时，会变得很麻烦
因此，一个很好的习惯是在传入的参数前加上final
public static int dayOfYear(final int month, final int dayOfMonth, final int year) {
...
}好好命名
每一个类，变量，都要有一个有意义的名字，这个名字也要符合（约定俗成的）规范
有一下几点：
-
方法
主要为动词
methodsAreNamedWithCamelCaseLikeThis -
变量
主要为名词
variablesAreAlsoCamelCase -
static final的常量CONSTANTS_ARE_IN_ALL_CAPS_WITH_UNDERSCORES
-
类
ClassesAreCapitalized -
包
packages.are.lowercase.and.separated.by.dots
不要使用全局变量
java中，用public static声明的变量就是全局变量
public static int LONG_WORD_LENGTH = 5;因为是全局的，所以程序的任何部分都可以访问，又因为是变量，大家都可以对它进行修改，这样就有很多的隐患，它可能在不经意间被程序的不知哪个部分给修改了
全局常量则被广泛运用，用public static final来声明一个全局常量
当然，final后面得跟着immutable的类型才行（包括所有的基本数据类型）
方法应该返回结果，而不是输出到控制台
这是新手很容易出现的问题，对于一个方法而言，它只应该完成它的本职工作，利用传入的参数进行计算，然后再返回结果，而不是输出到控制台
输出操作往往是代码最高层的部分（与人交互的部分）做的事情（比如main函数）
转载：https://blog.csdn.net/weixin_43740821/article/details/106266454