代码整洁之道

代码质量和整洁度成正比

 

有意义的命名,原则:

名副其实(用注解来补充的命名不是名副其实);

避免误导，避免使用与本意相悖的词汇；

做有意义的区分：Variable永远不要出现在变量中，Table永远不要出现在表中，废话是冗余的；

使用读得出来的名称；

使用可搜索的名称（单字母和数字常量很难搜索,exception的e也不好搜索）；

单字母名称仅用于短方法的本地变量，名称长度应与其作用域大小相对应；

避免使用编码；

不必使用m_成员前缀来表明是成员变量；

接口的I前缀不如实现的imp后缀；

避免思维映射：不应当让读者把你的名称理解为他们熟知的内容；

类名和对象名应该是名词或名词短语，不应该是动词；

方法名应该是动词或动词短语；

每个概念对应一个词；

别用双关语：同一单词用于不同目的；同一术语用于不同概念；

使用解决方案领域名词；

使用领域术语；

添加有意义的语境；

 

一言以蔽之：取名最难的地方在于需要良好的描述技巧和工有的文化背景。

 

函数

第一原则是函数要短小；第二条原则还是更短小。

一个函数只做一件事，并做好这件事（判断是不是做了一件事：看能不能再拆分一个函数出来）；

每个函数一个抽象级；

Switch语句：放于接口中，继承类则隐藏该部分，实现函数短小；

函数命名使用描述性的名称；

 

函数参数

最理想的是0参数，尽量少用3个参数以上的;多于的话,要考虑封装成类;

使用异常代替错误返回码;

抽离try catch块，将try中的逻辑封装成函数；

 

注释

注释存在的时间越久，就离其描述的代码越远，越累越变得全然错误，原因在于，程序员不能坚持维护注释

 

注释不能美化糟糕的代码；

唯一真正好的注释是不去写注释；

注释可以用于放大某种不合理的事物的重要性；

 

坏注释：

喃喃自语：如果决定要写注释就要写好注释；

误导性注释

错误注释

日志式注释：记录代码的修改——冗长的记录只会让模块变得凌乱不堪，删掉

 

能用函数或变量时就别用注释

 

归属和署名不必放在代码中，代码管理工具是这些信息的归属地

直接把代码注释掉是讨厌的做法

HTML注释不要存在于代码中；

非本地注释：注释内容与被注释代码脱离上下文关系；

 

短函数的函数头注释不如起个好的函数名字；

 

格式

代码格式关乎沟通，沟通是专业开发者的头等大事

 

纵向格式

尽可能用200行，不超过500行的代码文件

 

变量应该尽可能靠近其使用位置；

实体变量在类顶部声明；

相关函数：调用者放在被调用方法的上部；

概念相关：概念相关性强的代码放在一起；

 

横向格式

代码行尽量短小

方法名和左括号不必加空格，参数一一隔开；

 

 

对象和数据结构

对象把数据藏于抽象之后，暴露操作数据的函数；数据结构暴露数据；

 

对象和数据结构的二分原理：

过程式代码(使用数据结构)在于不改变既有数据结构的前提下增加新函数,面向对象的代码便于在不改变既有函数的前提下增加新类.

反之,过程式代码难以添加新的数据结构,因此必须修改所有函数.面向对象代码难以新函数,因为要修改所有类.

 

数据传送对象:DTO,只有公共变量,没有函数

 

错误处理

使用异常而非返回码

别返回null值,别传递null值

 

边界

使用第三方代码

 

类

类要短小：单一全责原则

内聚

 

系统

将系统的构造和使用分开

 

迭代

通过迭代设计达到整洁的目的