代码正规化之代码整洁之道

2018年02月03日

阅读:793

命名:

1、有意义,名副其实:降低代码的模糊度,明确说明代码的用途;

2、避免误导:accountList的类型最好就是List;

3、避免使用多个不同之处较小的名称;

4、避免使用字母l和O,因为它们像数字1和0;

5、做有意义的区分,只有意义不同时才使用不同的名字;

6、废话是无意义的区分,是冗余;

7、使用可搜索的名称:用宏定义数字比直接用数字好,避免使用单字母变量和数字常量;

8、不必使用带类型的匈牙利标记法;

9、避免成员变量使用类名前缀;

10、类名和对象名一般都是名词和名词短语;

11、方法名一般是动词和动词短语;get,set,is前缀;

12、使用解决方案领域内的名称;

13、添加有意义的语境:使用有意义的前缀,创建一个类并将变量声明为成员变量;

14、命名要精确:不要添加无意义的语境;

函数:

1、短小:函数中的缩进层级不应该多于一层或者两层;

2、函数应该做一件事,做好一件事,只做一件事;

3、每个函数只有一个抽象层级,其他的交给下面的抽象层来做;

4、判断函数只做了一件事:不能分函数区段;

5、阅读代码,自顶向下规则:每个函数后面都跟着下一个抽象层的函数;

6、如何让switch只做一件事:通过类工厂创建实际类并返回父类引用,再使用抽象类(父类引用)调用实际类重写的函数;

7、使用描述性的名字;

8、函数参数:为了便于测试,应该少于2个;

9、一元函数的3种形式:

①询问关于参数的问题(判断),②转换参数的内容(要有返回值),③参数是个事件(无返回值)

10、如果函数超过2元:应该将其中的某些参数封装成类;

11、函数名字:动/名词形式;

12、避免使用输出参数:如果需要,应该修改所属对象的状态;

13、一个函数要么做一件事(指令),要么回答一件事(询问);

14、使用异常代替返回错误码:这样错误代码可以从主路径代码中分离出来,避免嵌套;

15、分离try/catch块:集中在一个函数中;

注释:

1、整洁清楚的代码比注释要好得多;

2、真正好的注释就是考虑不用写注释;

3、需要注释的地方:提供法律信息;解释方法的意图;提供警告信息;

4、ToDo注释,提示尚未完成的工作;

5、避免括号后面的注释,应当减少嵌套,写成方法;

6、删掉被注释掉的代码;

7、注释就是一种失败;

格式:

1、垂直上的间隔:不同的逻辑之间用空格间隔;

2、垂直上的靠近:关系密切的逻辑要靠近才会更加清晰;

3、变量在离使用最近的地方声明;

4、相关函数:放在一起,调用者放在被调用者的上面;

5、概念相关:命名模式相同,应该放在一起;

6、水平方向:以不拖动滚动条为准则;

7、=,+=等前后的空格可以起强调的作用;

8、缩进

9、团队规则

对象和数据结构(过程式代码):

隐藏实现关乎抽象,并不是简单的添加取值器和赋值器;

1、对象和数据结构的反对称性:

过程式代码便于在不改变既有代码的同时,添加新的函数(过程);

面向对象便于在不改变既有函数的情况下,添加新的类(对象),但是如果抽象类添加新的函数,就需要修改抽象类的所有子类;

2、数据结构应该只有公共变量;对象应该只有私有变量和公有函数;

3、对象暴露行为,隐藏数据;便于添加新对象类型而无需修改既有行为,同时也难以在既有的对象中添加新行为。

数据结构暴露数据,没有明显的行为;便于向既有数据结构添加新行为,同时也难以向既有函数添加新数据结构。

4、Thelawofdemoter:模块不应了解它所操纵对象的内部情况。火车失事,混杂,隐藏结构。

错误的处理:

1、不要返回null值:这样的话调用者就要处理null,增加工作量;

解决:抛出异常或者返回特例对象;

2、不要传递null值:

3、异常的处理:抛出异常或者返回特例对象;如果是调用第三方api可能产生异常,可以新建一个方法或异常类将第三方api打包;

4、避免使用可控异常(checkedexception):因为处理它们需要修改函数头,违反了开放-闭合原则;应该使用不可控异常(runtimeexception),

保持边界整洁:

1、学习性测试:在项目中引入第三方api的新版本,测试项目是否正常工作;

2、处理边界问题方法:用新类包装第三方api;用adapter模式将我们的接口转换为第三方提供的接口;

单元测试:

1、测试驱动开发,整洁的测试有助于进行代码的改动;

2、整洁测试的标准:可读性;

3、双重标准:由于运行环境的差异,测试代码和生产代码可以有不同的标准,如效率、内存等;

4、单个测试的断言数量应该最小化,只测试一个概念;

5、F.I.R.S.T规则:

Ffast:测试需要频繁运行,因此要能快速运行;

IIndependent:测试应该相互独立;

RRepeatable:测试应当能在任何环境中重复;

SSelf-validating:自足验证,测试应该能看到成功与否的结果;

Ttimely:测试应该及时编写,应该恰好在生产代码之前编写;

类:

1、类的组织:自顶向下原则,变量列表(公共先于私有,静态先于实体),方法列表(工具方法紧跟在所属方法之后);

2、类应该短小:类名越明确,类的职责就越清晰;

(1)每个类单一权责,只有一个修改它的原因,并与少量的其他类协同完成工作;

(2)内聚:类中含有最少的变量,且每个方法都使用每个变量,此时内聚度最高,类应该是内聚高的;

3、隔离修改:具体类实现细节,抽象类只呈现概念,利用接口和抽象类可以隔离因为细节的改变而带来的改变类的风险;

系统:

1、构造与应用代码应该隔离开:就好像建设大楼时,构建大楼的吊车、铲车之类的东西,在大楼投入使用时已经完全不存在一样;软件系统应该讲启动过程和启动过程之后的运行时逻辑分开,在启动过程中创建应用对象,也会存在相互的依赖。

publicServicegetService(){

returnnewMyServiceIml(...);

}

这种延迟化赋值的好处是:在使用对象之前不用关心这种架空构造;坏处是:必须实现这个构造方法,不然无法编译,即使这个对象在运行时永远不会被使用。

解决方法:

(1)分解main,将系统中的全部构造过程搬迁到main或者main模块中:main函数创建对象,再将对象传递给应用,应用直接使用;

(2)工厂,可以让应用控制实体创建的时机;

(3)依赖注入,控制反转IoC是依赖管理的手段,它将应用需要的依赖对象的创建权责从对象中拿出来,放在一个专注于此事的对象中,并通过依赖注入(赋值器)将依赖对象传递给应用;

2、扩容

AOP,面向方面变成。Java中三种方面和类似方面的机制:代理,纯AOP框架,AspectJ

(1)Java代理:Proxy.newInstance(被代理接口,InvocationHandlerh)方法执行后,被代理类的所有方法都会被加上Handler的处理逻辑,这是简单的AOP,但是太复杂;

(2)纯AOP框架:SpringAOP(需进一步了解)

(3)AspectJ语言

最佳的系统架构由模块化的关注面领域组成,每个关注面均用纯Java对象实现。不同的领域之间用最不具有侵害性的方面或类方面工具整合起来。这种架构能测试驱动,就像代码一样。


别逗了好么

努力每一天,奋斗为明天。

文章 981 作品 25,341

热门作品

文章推荐

猜你喜欢

榜上有名

广告