代码整洁之道阅读笔记 一

一、命名

全员生产维护

整理

整顿

清楚

清洁

身美

简单代码规则

能通过所有测试

没有重复代码

体现系统中的全部设计理念

包括少量的实体，比如类、方法、函数等

变量的命名

名副其实，它为什么会存在，它做什么事，应该怎么用。如果需要注释来解释，那就不是名副其实

int d//消逝的时间 以天计
int elapsedTimeInDays
int daysSinceCreation
int daysSinceModification
int fileAgeInDays

- 有意义的命名，  不要$a  $d 等
- 命名不要冗余, 比如在table的命名里永远不加table   变量的命名里不加variable
- 能读得出来的命名 不要 genymd(生成年月日)  换成generationTimeStamp

类的命名

类名和对象名应该以名词或者名词短语为主，避免使用动词

方法名 尽量使用动词或者动宾结构并依Javebean标准加上get set is 前缀 5.终上所述，明确！就是要明确！不要前缀不要一语双关等等。 6.最后的话：取好名字最难的地方在于需要良好的描述和共有文化背景。与其说这是一种技术、商业或者管理问题，还不如说是一种教学问题。其结果是，这个领域内的许多人都没能学会做得很好。

二、函数

函数就应该短小 一个函数最好不要超过20行

函数应该只做一件事，做好这件事，只做这件事

函数要么做什么，要么回答什么，不要两者兼有

if(set('name','password'));
//改为
if(attributeExists('name')){
setAttribute('name','password');
}

别重复自己: 遵从DRY规则

如何写出这样的代码：写代码和写别的东西很像。在写论文或文章时，你先想什么就写什么，然后再打磨它。初稿也许粗陋无需，你就斟酌推敲，直至达到你心目中的样子

小结：每个系统都是使用某种领域特定语言搭建，而这种语言是程序员设计来描述那个系统的。函数是语言的动词，类是名词。编程艺术是且一直是语言设计的艺术。

三、注释

只有当程序表达失败时，才需要用得上注释，真正好的代码是不需要注释的

注释不能美化糟糕的代码

用代码来阐述永远好过垃圾代码+注释

#example
if((employee.flags & HOURLY_FLAG)&&(employee.age)>65)
还是这个？
if(employee.isEligibleForFullBenefits())

好的注释：有些注释是必须的，也是有利的
法律信息

提供信息的注释

对意图的解释

阐释 注释把某些晦涩难明的参数或者返回值的意义翻译为某种可读形式

警示

TODO 注释 这个就非常有必要了，将来需要怎么做，个人挺喜欢用的，当前时间段内，由于某些原因还没有做，但是以后会需要做的事

放大 和警示差不多

坏注释，大多数注释都属此类。通常，坏注释都是糟糕的代码的支撑或借口，或者对错误决策的修正，基本上等于程序员自说自话。
多余的注释

误导性的注释

循规式注释，比如每个字段都加注释， title author等简单明了的变量

日志式注释，因为有代码控制 SVN GIT 不需要把每次变化都通过注释表示

废话注释

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

归属和署名 年代越久越和原作者没关系

注释掉的代码，直接干掉代码整洁之道阅读笔记