哪种代码，需要重构

内容会持续更新，有错误的地方欢迎指正，谢谢！

正文

1）注释：不恰当的信息，废弃注释，废弃代码，冗余注释
2）环境：尽可能容易构建，尽可能容易测试
3）函数：过多参数，输出参数，标识参数，死函数
4）明显的行为未被实现：类名或者函数名应当符合知觉，否则就需要使用的人详细读代码细节。
5）注意不正确的边界行为：不要依赖知觉，需要对各种边界条件进行判断处理。
6）注意警告：不要忽视这些告诉我们可能存在隐患的忠言。
7）注意重复：有重复说明我们遗漏了抽象；重复是万恶之源。
8）基类不要依赖于派生类：基类要对派生类一无所知。
9）删除死代码：根本不可能执行的代码不要留情面。对于没用的注释，变量，统统干掉。
10）垂直分隔：变量和函数使用和定义尽量不要太远，私有函数最好在首次使用它的函数下面定义。
11）注意前后一致：一些命名和使用等，统一用一套规则，利于阅读和修改。
12）不要人为耦合：比如一些外部的enum，放到类中，就无形造成了其他类和该类耦合。
13）特性依恋：类的方法尽量只对类中的变量和函数感兴趣，不要垂青其他类中的变量和函数。（只能说是尽量吧）
14）不要太晦涩：有可能我们写得很专业，但是给看得人需要花很久才能理解。
15）斟酌变量或内容的位置：遵循最小惊异原则，放在最符合人类知觉的地方。
16）注意静态方法：如果静态方法有多重表现，是否考虑是不是需要有多态，改为非静态实现。
17）使用解释性变量：让程序可读的最有效方法之一就是将计算过程使用的中间值全都改成有意义的命名。
18）函数名称表达其行为：如果必须查询函数实现或者文档才能弄明白函数是干什么的，就说明函数应该改个名字了。
19）理解算法：在真正完成函数之前，我们必须理解这个函数是怎么工作的，而且还要验证这种解决方案是否正确。
20）逻辑依赖改为物理依赖：原始数据和业务逻辑的依赖关系最好改为函数方法和业务逻辑之间的依赖关系。
21）用多态替代if/else或switch/case：优先考虑多态实现。
22）团队开发尽量使用同一套规则。
23）用命名常量代替魔数：一些数字最好使用命名常量来代替，否则难以修改与理解。
24）准确：消除代码中含糊和不准确的内容，明确自己为什么这么做。
25）结构基于约定：基类强制派生类实现抽象方法会比switch更加让人遵守这个约定。
26）封装条件：一些if语句进行判断，但是不好理解，可以直接将这个判断条件写成一个函数，判断时使用这个函数，方便理解。
27）避免否定条件：使用！判断没有肯定判断直白。
28）函数只做一件事。
29）掩蔽时序耦合：有些需要按照顺序初始化的，可以按照上一个作为下一个的输入。防止其他人误用。
30）别随意：结构太随意或者位置太随意可能会让人误用。
31）封装边界条件：把处理边界条件的代码集中到一处。
32）得墨忒定律：只和自己直接的朋友交谈。编写害羞的代码，只让其直接协作者了解内部，不要暴露给其他。
33）不要继承常量：把常量放在继承树最顶层并不是个好选择。不如静态导入。
34）名称作用域越大，名称就应该越长，越准确。
35）避免编码：现代编程环境不是很需要m_，f_等前缀。
36）名称说明副作用：比如获得一个物体，不存在就创建，用GetOrCreate就比Get容易理解。

参考

puppet_master的博客 https://blog.csdn.net/puppet_master/article/details/76356049