《Clean Code》第一章举了一个很深刻却不断发生的例子，它展示了一个项目为混乱代码所付出的代价；然后列出了诸位大师眼中整洁代码的含义，最后给出了著名的“童子军军规”：让营地比你来时更干净。之后的二到十二章讲述了作者及其团队关于各种整洁代码的技巧和建议；十三章和附录A是关于并发的讨论，有一定难度；十四至十六章以三个真实的代码案例演绎了编写整洁代码的过程、演进及重构，最后一章提出了常见混乱代码的“味道”，程序员应具备良好的嗅觉，以便在代码腐朽之前发现它，改善它。
当前的技术氛围下，一个人编写整洁的代码已经很难，要让一个团队如此更是难上加难。每个人的想法不一样，经历不一样，项目压力又那么大，如何才能保持代码的整洁呢？我认为有战斗力的团队要有共同的意识，这种意识应该书面化的表达出来，反应在技术团队中就是编码的规范。
以下几点，是我结合工作遇到的问题及书中的思想后所做的思考：
1、命名：前不久，我在工作中因变量命名而导致了一个BUG。creditcard_no，certificate_no前者是信用卡号，后者是身份证号，在现代IDE如此强大的智能提示下输入一个c就给出了建议，可你能一眼看出两者的区别吗？换个角度，这两个变量的命名是否应该包含下划线呢？信用卡号，身份证号这种常用名词是不是应该有个规范的命名以避免将来另一处出现一个identityCardNumber呢？
2、风格：一般情况下，我们最经常编写的接口就是数据查询接口了，这个接口叫什么名字呢？有人会以Search命名，有人习惯Query开头，单独看来都是好的名字，可放在一起就容易制造混乱。那么我们是否应该规定一种命名风格以避免将来付出的代价呢（特别是暴露给第三方使用的接口，代价更大）？
3、工具类：如果一个程序员有良好的抽象意识，当他在编码中发现一些重复的代码想提炼出来作为一个工具类使用时，他疑惑了，因为他不知道这个类该叫什么名字，该放在哪？于是要么他保持原状不做修改，要么自己找了个地方扔进去，于是坑又多了一个。作为规范的制定者，是不是应该事先挖一个坑以便这些东西有地方放呢？
4、注释：说到规范，相信很多团队都有或曾经有过一条规范“类和方法必须写注释”，于是我们在每个类的上面看到一堆作者信息，即使这个作者只负责把现成的算法敲进屏幕，通常里面还包含了类的创建日期及实现功能，提醒你每次修改时都要标名日期和内容；方法也如此，大部分的注释就是把方法名翻译一遍，于是下一个阅读者的阅读时间需要乘以二；时不时得你还会看到几个被注释的方法，你敢删吗？好吧，一些版权和特殊算法的说明是必要的，可在代码管理工具如此发达的今天，我们有必要强制编写这些冗余的注释吗？通常情况下，这么做的结果要么是注释占代码总行数的一半以上，要么就是一堆文不对意的古老文字。
5、null：如果没有规范，很多人在编写方法时的开头一句都是对参数是否为null的判断，很多团队还把此当做“规范”。好吧，如果你遵循“小既是美”，那么最后你会发现，一个方法总共就五六行代码，三分之一都是这种判断。null是一个很讨厌的东西，作为个体我们有必要消除它的隐患，可作为一个系统，我们应该在合适的层次集中阻断，不要给底层制造太大的压力。
6、不加{}：职责单一，小既是美是当今流行且认可的思想，在这种思想下，方法应该足够小，基于此，流程语句也应该足够短，那么我个人作为一种试验，强迫自己所有的流程语句不加{}，这样在流程语句中你只能写一句话，这句话通常就是一个函数的调用。你可能觉得这样不太好看，但我觉得那是你还不习惯，当方法足够短时，两个括号都显得臃肿。当然，这是我个人的试验。
7、数据结构：很多时候，数据结构远比程序本身重要。新版的新浪微博新增了动态展示功能，将你关注的人，参加的活动都显示出来，如果是一个时间段内的多条类似动态，它会合并成一条显示。奇怪的事来了，对于单独的一条动态，你可以删除，多条合并的动态却无法一起删除；近期微博的解决方案是对于新的动态不再合并，但老的不管了。好了，你能想象新浪微博动态的数据结构是什么样的吗？
8、单元测试：现在都推敏捷，推单元测试，可是如果你连正式代码没有规范，你的单元测试会写成什么样？原本你寄托于依靠单元测试来改善现有的混乱代码，但通常的结果是，你得到了两套混乱代码。
那么什么是好的规范？我认为好的规范要体现这四个字：先知后觉。你想做的我已经想到了，而且写完后回过头一看，团队的代码像一个人写得一样。你也许觉得这不切实际，但我们就是要有一个伟大的梦想。通常情况下，想当将军的士兵只能成为校官，而想当皇帝的士兵......好吧，我不多想了。
团队的规范通常是一个大牛或一个大牛委员会制定的，但不可能永远不变，我们需要有个开放且固定的地方供大家讨论，并有良好的修正、通知机制。
恩，人人定规范，规范定人人。为了写出整洁的代码，让我们制定一套适合自身的规范吧！