由于工作上的原因,阅读了《代码整洁之道》的前十章,读完之后,心有余悸。之前对自己代码的整洁度还是有点信心的,在变量的定义上、方法名的定义上、方法的编写上和对类分层上,都有特别大的提升修改空间,不禁开始想起之前学习别人的代码,现在才明白一点,他们的设计是有深意的,深感惭愧。
下面是按照《代码整洁之道》前十章给自己的总结:
1、整洁代码:
让营地比你来时更干净!
2、命名:
①需要名副其实,命名应该告诉你它为什么会存在,它做什么事,应该怎么用。
②避免使用与本意相悖的词。
③名称长短与其作用于大小相对应,若变量或常量可能在代码中多处使用,则应赋予其便于搜索的名称。
④类名和对象应当是名词或名词短语,方法名应当是动词和动词短语。
⑤添加有意义的语境。
⑥别害怕长名称,长而具有描述性的名称比短而费解的名称好
3、函数:
①函数应该短小,并且更短小。
②函数应该做一件事。做好这件事。只做一件事。
③要确保函数只做一件事,函数的语句都要在同一抽象层级上。
④方法中的参数,尽可能少。若参数过多,可以考虑封装成类。
⑤给函数的命名,应该能较好解释函数的意图,以及参数的顺序和意图。
⑥拒绝布尔型标识参数。例:render(boolean isSuite) ==> renderForSuite() 和 renderForSingleTest()
⑦使用异常代替返回错误码,错误处理代码就能从主路径代码中分离出来得到简化。
4、注释:
①注释应该减少,尽量用代码来阐述自己。
②一段糟糕的代码,注释救不了,还是需要重构。
③注释的最佳用处:法律信息、提供信息的注释、对意图的解释、阐述晦涩难懂的部分、TODO。
5、格式:
①源文件最顶部应该给出高层次概念和算法,直至底层的函数和细节。(向报纸学习)
②关系密切的概念应该互相靠近,避免使用protected。
③声明变量应尽可能靠近其使用位置。
④实体变量应该在类的顶部声明。
⑤相关函数应该放在一块。
⑥概念相关的代码应该放在一起。
6、对象和数据结构:
①对象把数据隐藏于抽象之后,只提供操作数据的函数。数据结构暴露其数据,没有提供有意义的函数。
②(The Law of Demeter)模块不应去了解它所操作的对象内部细节。
7、错误处理:
①使用异常代替返回码。
②不返回null值。
③禁止传入null值。
8、边界:
①善用测试来学习。
9、单元测试:
①善用测试来学习。
②测试代码和生产代码一样重要,应该像生产代码一样保持整洁。
③每一个测试一个概念。
10、类:
①类应该足够短小。
②类的声明顺序:公共静态常量->私有静态变量->私有实体变量->公共方法->私有方法
③单一职责原则:类或模块应该有且仅有一条加以修改的理由。
④内聚:类应该只有少量实体变量,类中的每个方法都应该操作一个或者多个这种变量。类中的方法和变量应该互相依赖、互相结合成一个逻辑整体。
⑤对于一个类的新特性,最好通过拓展系统而非修改现有代码来添加新特性。