最新要闻

广告

手机

iphone11大小尺寸是多少？苹果iPhone11和iPhone13的区别是什么？

iphone11大小尺寸是多少？苹果iPhone11和iPhone13的区别是什么？

 警方通报辅警执法直播中被撞飞：犯罪嫌疑人已投案

警方通报辅警执法直播中被撞飞：犯罪嫌疑人已投案

家电

  1. 首页
  2. 移动通信
  3. 内容

全球今日报丨读C#代码整洁之道笔记04_重构C#代码识别代码坏味道

来源：博客园

1.应用程序级别代码坏味道

1.1.布尔盲点

  • 1.1.1.由于函数使用布尔值而导致的信息缺失

  • 1.1.2.解决方案是将布尔替换为枚举类型

1.2.组合爆炸

  • 1.2.1.不同的代码使用不同的参数组合来执行同一件事情的产物


    (资料图)

  • 1.2.2.解决方案使用泛型

1.3.人为复杂性

  • 1.3.1.简单的架构复杂化

  • 1.3.2.解决方案务必保持软件的简单易懂（Keep It Simple，Stupid，KISS）

1.4.数据泥团

  • 1.4.1.相同的字段同时出现在不同的类和参数列表中时

  • 1.4.1.1.说明系统中缺少类定义

  • 1.4.2.识别并泛化缺失的类可以降低系统的复杂度

1.5.粉饰注释

  • 1.5.1.注释中用优美的词句掩盖代码的缺点

1.6.重复代码

  • 1.6.1.多次出现的代码

  • 1.6.1.1.bug=技术债务=程序员支出

  • 1.6.2.解决方案将这些代码添加到当前项目的可重用类并放置在类库中

  • 1.6.3.解决方案2：面向方面编程（AOP）是另一种删除样板代码的方法

1.7.意图不明

  • 1.7.1.他人无法轻易理解代码的意图

1.8.可变的变量

  • 1.8.1.不同操作之间多次更改的变量

  • 1.8.2.消除变量的可变性，使其值更易于预测

  • 1.8.3.函数编程

  • 1.8.3.1.LINQ

1.9.怪异的解决方案

  • 1.9.1.源代码中解决同样问题的方案多种多样

  • 1.9.1.1.源代码中解决同样问题的方案多种多样

  • 1.9.1.2.没有制定统一标准而造成

  • 1.9.1.3.程序员并没有意识到系统中已经存在解决方案

  • 1.9.2.解决方案：不同的重复的解决方案编写新类，并将最整洁最高效的方式添加到类中

  • 1.9.3.解决方案2：适配器模式来统一不同的系统接口

1.10.霰弹式修改

  • 1.10.1.一种改动需要在多个类中进行修改

  • 1.10.1.1.复杂的代码还会导致程序员认知负担过重

  • 1.10.2.减少耦合可以使类更易于测试

  • 1.10.3.将不属于类的代码移出到恰当的位置可以提高应用程序的可读性、可维护性与可扩展性

1.11.解决方案蔓延

  • 1.11.1.一种职责在不同的方法、类甚至库中均被实现

  • 1.11.2.单一职责转移到同一个类中

1.12.不可控的副作用

  • 1.12.1.在产品中由于无法被质量保证过程发现而引起的问题

  • 1.12.2.唯一的办法就是重构代码使其完全可测，并可以在调试期间查看变量的状态以确保程序的正确性。

2.类级别代码坏味道

2.1.过高的圈复杂度

  • 2.1.1.大量的分支和循环

  • 2.1.2.1～10

  • 2.1.2.1.代码简单没有风险

  • 2.1.3.11～20

  • 2.1.3.1.较复杂，风险相对较低

  • 2.1.4.21～50

  • 2.1.4.1.引起注意，中等风险

  • 2.1.5.超过50

  • 2.1.5.1.风险高，必须重构

  • 2.1.6.解决方案

  • 2.1.6.1.使用工厂模式替换switch语句

  • 2.1.6.2.改善if语句条件检测的可读性

  • 2.1.6.3.LINQ语句替换循环

2.2.发散式变化

  • 2.2.1.对代码进行一处更改，但是发现自己必须更改许多不相关的方法

  • 2.2.2.原因

  • 2.2.2.1.类结构不良造成

  • 2.2.2.2.复制粘贴代码

  • 2.2.2.3.利用基类和子类的关系实现继承

2.3.向下类型转换

  • 2.3.1.将基类转换为它的一个子类

2.4.过度的字面量使用

  • 2.4.1.将字面量保存在常量中

  • 2.4.2.将字符串字面量放置在本地化资源文件中

2.5.依恋情结

  • 2.5.1.当一个方法花费大量的时间处理类中的代码而非自身的代码

2.6.狎昵（xiá nì）关系

  • 2.6.1.一个类若依赖另一个类的实现细节

  • 2.6.2.类之间不应当相互依赖

  • 2.6.3.类应当是自包含的

  • 2.6.4.类之间应该尽可能少地互相了解彼此的底细

2.7.不恰当的暴露

  • 2.7.1.类暴露了其内部细节

  • 2.7.2.打破了面向对象编程的封装原则

2.8.巨大的类

  • 2.8.1.务必令其尽可能小巧、整洁、易于阅读

2.9.冗赘类

  • 2.9.1.一种并不包含什么有效操作的类

  • 2.9.2.和其他包含相似意图的类合并

  • 2.9.3.削减继承层次结构

  • 2.9.3.1.理想的继承层次是1

  • 2.9.4.非常小的类还可以考虑采用内联的处理方法

2.10.中间人类

  • 2.10.1.仅将功能委托给其他对象

  • 2.10.2.舍弃中间人直接和处理相应职责的类进行交互

  • 2.10.3.将其与现有类合并

2.11.孤立的变量和常量类

  • 2.11.1.使用一个独立的类来定义系统不同部分使用的变量和常量

  • 2.11.2.丢失其上下文而无法表达任何实际含义

  • 2.11.3.移动到使用它们的位置

2.12.基本类型偏执

  • 2.12.1.使用常量作为字段名称

  • 2.12.2.不恰当地使用常量保存信息

  • 2.12.3.使用基本类型值而非使用对象

2.13.被拒绝的遗赠

  • 2.13.1.一个类继承自另一个类，却没有使用其所有方法

  • 2.13.2.考虑是否真的需要基类

2.14.夸夸其谈未来性

  • 2.14.1.一个类的功能现在不需要，但是将来可能用到

  • 2.14.2.死代码，应当将其删除

2.15.命令，而非询问

  • 2.15.1.将数据和操作数据的方法绑定在一起

  • 2.15.2.一个对象包含逻辑，并要求其他包含数据的对象提供数据以供其执行操作，则应当将逻辑与数据合并到一个类中

2.16.临时字段

  • 2.16.1.不需要在对象的整个生命周期内存在的成员变量

  • 2.16.2.将临时字段及操作这些字段的方法移动到它们自己的类中

3.方法级别的代码坏味道

3.1.不合群的方法

  • 3.1.1.一个类中和其他方法截然不同的方法

  • 3.1.2.考虑该方法的目的

  • 3.1.2.1.确定哪里才是该方法最合适的落脚点了

3.2.无用的代码

  • 3.2.1.现存的方法无人使用

  • 3.2.2.要识别无用的代码并将其删除

  • 3.2.3.构造器、属性和变量也应遵循相同的原则

3.3.过多的返回数据

  • 3.3.1.远超客户端的调用

3.4.过长或过短的标识符

  • 3.4.1.标识符应当既能描述对象又简明扼要

3.5.过长的代码行

  • 3.5.1.应尽量将其格式化，在点号和逗号处换行

3.6.过长的方法

  • 3.6.1.方法应当只负责执行单一任务

3.7.参数过多

  • 3.7.1.方法参数数目超过3个

3.8.过度耦合的消息链

  • 3.8.1.当一个方法调用一个对象，继而调用另一个对象

  • 3.8.2.消息链违反了迪米特法则

  • 3.8.2.1.类只应当和离其最近的邻居通信

  • 3.8.2.2.重构类，将所需的状态和行为放在距离其更近的位置

3.9.过高的圈复杂度

3.10.人为复杂性

3.11.依恋情结

3.12.狎昵关系

3.13.冗赘方法

3.14.中间人方法

3.15.怪异的解决方案

3.16.夸夸其谈未来性

3.17.参见前文

关键词：