代码坏味道之令人迷惑的暂时字段

为什么我们随意命名变量会是灾难性的决定?

随意命名变量是编写代码的灾难性决定,我这里说的比较严重,但是为了强调编程过程中不要随意命名我们的变量。因为从以下三方面的理由是不允许我们在程序中随意命名变量的。首先在编程过程中,随意命名的变量会导致我们编写代码中弄乱数据传输的关系,因为人们通过混乱的字段会把字段的本意理解错误的,理解错误字段的意思就会把该字段用在本不该她使用的地方。其次,当你费尽千辛万苦程序终于能够运行了,但是面对需求变更或代码给其他人阅读的时候,会给阅读人带来很大的难度,因为当别人来阅读的时候在令人迷惑字段上面耗费很大的精力去理解。最后,当你是一个老员工使用这么不规范的编码习惯,你带出来的徒弟也会随意命名,因为初入职场的新人是对技术上混了几年的老鸟有一种敬佩之情,作为老鸟的我们不能给新员工模范错误的榜样。

随意命名不仅是自己对代码的不负责任,而且还会让自己带出来的程序员对你怀恨在心,说以随意命名是灾难性的。

为什么要把变量集中管理或通过配置来管理呢?

我们可以采取的办法有哪些呢?通常我们可以采用以下两种方式进行管理。首先可以使用Extract Class给这些孤儿创造一个家,然后把所有和这个这个变量相关的代码都放进这个新家里,当然在放入新家的成员能够给这些字段赋予明确意义的名称,名称可以通过字段的职责抽象进行命名,做到见名知意的效果。其次,可以把这些字段放入固定的资源文件或配置文件,为什么要这样做呢?因为通过配置文件程序在不停机的情况下可以修改变量的值,同时也做到了把字段进行了集中管理,但是字段放在配置文件中每一次程序都需要进行文件操作,读取相应的字段里面的变量值。在以上两种解决方案中应该综合利弊权衡优劣采取相应的策略。

代码坏味道之令人迷惑的暂时字段

时间: 2024-10-14 11:40:33

代码坏味道之令人迷惑的暂时字段的相关文章

代码坏味道特征重复的代码

重复的代码开发,在作为初级的程序员是经常遇见的,因为被要求做一些很固定且比较简单通用的模块,所以很容易就遇上功能相同的代码进行重复的开发了. 1.为什么会有重复的代码 重复的代码可能会出现编写人员抽象公有模块抽象公有功能的能力,可能来自我们开发方式过于老化固定了类之间的相互应用所以导致编写的某一个功能只适用一个特定的系统使用,可能来自我们的设计人员对项目框架设计考虑不够仔细,没有重用性的设计过程. 2.怎样避免出现重复的代码 使用完善的SOA框架,我认为至少在我们内网程序开发中可以节约一大部分的

代码坏味道之过长的参数列

1.为什么会出现过长的参数的函数呢? 出现过长的参数列,我们在编写程序的时候职责划分不清晰,一个函数做了太多的事情,可能会让调用者传入更多的参数进行功能的实现.第二函数封装不合理,导致调用函数的内部变量成为封装函数的参数. 2.当我们遇上了过长的参数函数怎么办? 当我们遇上了过长的参数列的函数有两种方法来解决,第一,通过重载参数把程序中暂时不需要的函数的参数进行封装,减少过长的参数列.第二,通过封装参数列对象,在封装的时候尽量将职责相近的参数放在一起,这样做提高了封装对象的内聚性. 3.怎样避免

吐槽一下项目中的代码坏味道:滥用java常量

我们的项目中是否充斥着类似下面的代码呢?定义一个专门存放常量的java类(接口),很多其他类依赖该常量类. public interface IConstant { int ZERO = 0; String EMPTY_STRING = ""; } 使用该常量的代码,大致具有如下形式: List<String> list = new ArrayList<String>(IConstant.ZERO); if(IConstant.ZERO == list.size

代码坏味道之过大的类

1.为什么会出现过大的类 我们的编码过程中,不知不觉的就把一个类编写的非常的庞大.为什么会这样子呢?我想无非由两个理由,首先是编码过程中为了贪图一时的方面不想动手去添加一个类用来管理不属于原先这个类的职责.其次整个系统使用了太多的继承关系,无形中就会造成子类变得异常庞大.总之,如果想利用一个类做太多的事情,往往就会造成这个类变得异常庞大.8 2.过大的类会照成什么严重后果 既然出现了过大的类,那么他到底会造成什么严重的后果呢?首先很明显一点过大的类在开发中难以调试并且在后期维护中可能因为功能的变

代码坏味道之夸夸其谈的未来性

1.为什么会有夸夸奇谈的未来性呢? 当我们谈到这个问题的时候,我们就要反思在需求理解和设计的时候对程序变动性的理解出现了偏差."哦,我想我们总有一天炫耀做这事儿的"常常是一念之差导致的代码坏味道.总结有以下四点原因是经常导致出现夸夸奇谈未来性的原因.第一.经常在理解需求的时候主观的认为需求变动非常大,那么在设计过程中就会出现过度的设计.第二.追求设计模式的使用,经常对程序的不必要的地方进行设计模式的使用,导致代码不易理解.第三.程序的设计过程中封装变化混乱,没有将封装变化进行到底.最后

代码坏味道 - 耦合

耦合 Feature Envy 症状: 方法访问其他类的对象的属性,而不是自己的. 成因: 最常见的问题就是由数据类引起的. 治疗: 多数时候,同时需要做出改变的code 应该在一起. 收益: 不合适的亲密 症状: 一个类有大量的访问另一个类的属性和方法,类之间的联系千丝万缕. 成因: 治疗: 变双向依赖为单向 单点接触 收益: 消息链 症状: a.b().c().d() 有什么不好吗? 客户对这关系知道的太多了,修改关系就意味着修改所有客户. 成因: 治疗: 隐藏委托,变单点接触.a 通过b

『重构--改善既有代码的设计』读书笔记----代码坏味道【3】

星期六了,适当出去放松了下,回来继续我们重构的话题.今天是坏味道[3]了,很多朋友跟我私信,叫我把坏味道出完,再出手法.其实这是有道理的,很多时候,"发现"远比"怎么做"重要的多.就拿设计模式来讲,GoF里面的设计模式相信有很多人都了解过.具体的设计模式应该怎么实现啊相信有很多人都背的滚瓜烂熟,但问题的难点往往在于你应该什么时候用这个设计模式.重构也一样,手法步骤都是死的,关键在于应该发现什么时候应该重构.所以,我还是决定继续出坏味道,把坏味道全部出完我们再去学手法

javascript编程中一种常见的代码坏味道:Pyramid of doom(金字塔厄运)

Pyramid of doom说的是代码嵌套层次太深,太多的代码缩进,导致代码横向增长大于纵向增长.非常影响代码的可读性,因为我们看不清嵌套关系,很容易弄错变量的作用域,大括号多了或者少了等问题. 代码1:if层次过深 bool conditionA = executeStepA(); if (conditionA){ bool conditionB = executeStepB(); if (conditionB){ bool conditionC = executeStepC(); if (

代码坏味道

肿胀 代码,方法或类膨胀到难以维护,一般是长期积累形成,从未人尝试瘦身. 这包括: 长方法,大类,长的参数列表,偏爱使用原始类型,数据块 对 OO 的滥用 对面向对象原则的不正确或一知半解. switch 语句, 临时字段, 拒绝继承,Alternative classes with different interfaces 阻碍改变 修改一处,要同时修改很多处.程序开发变得越来越复杂和麻烦. Divergent Change , Shortgun Surgery, Parallel Inher