代码=诗=散文

    干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好基础。对于软件而言，百分之八十以上的工作集中在我们美其名曰“维护”的事情上：说白了就是修修补补。因此一份干净整洁、质量上层的代码对于提高程序员的工作效率是无比的重要。对于代码，应无情的做重构。重构的周期可能以周、天甚至小时计。细节中自有天地，我们坦诚代码状态，因为它永不完美。稍后等于永不，开始你的诗与散文之旅吧！

1 整洁代码

  只要你是一名程序员，我相信你一定就会有过被某人糟糕代码绊倒过的经历。有些项目前期进展迅速，但是随着项目的进展，项目的进展速度会越来越慢，最终会慢如蜗牛。为什么，因为代码的修改和维护存在于代码的整个生存周期里，而对代码的每次修改都会对其它地方的代码产生影响。随着代码的修改越积越多，乱麻就越来越大，最后变得无法清理，大家只能束手无策，团队的生产力也会持续下降，直到为零。

  当以上情况发生时，管理层为改变现状往往只有两个选择：增加更多的人手到项目中，期望提高生产力；抛弃原有代码，要求做全新的设计。第一个选择，新人并不熟悉当前设计，不明白原有设计意图。但是他们又背负着巨大的压力，不得不对当前程序做出不一样的修改。于是他们会制造更多的混乱，使团队的生产力降的更低。第二个选择，管理层会组建一支全新的团队，这个团队每个人都想加入，因为它是一张白纸，每个人都可以尽情的施展自己的才华，但是往往只能是最优秀的人才能加入其中，其余的人只能继续维护现有的系统。现在就变成的新旧两支队伍在竞赛，新团队需要搭建一套新的系统用以替换旧系统的所有功能，而老团队又在不断的根据现场需求，添加许多的的功能。这种平衡会一直持续，可能是一年、两年，更甚至十年，直到新系统能够完全替换旧的系统。等有一天，新的系统终于完成，新团队的老成员已经不知去向，而新团队的现有成员则要求重新设计一套新的系统，因为这套系统太烂了。当你经历过或意识到这个死循环的时候，你就会发现花时间保持代码整洁，提高代码的维护和扩展，不止关乎效率，更是关乎生存。

  整洁的代码是什么，什么是整洁的代码，就像一千个人眼中有一千个哈姆雷特一样，每个人都有自己的一套标准。我们无法评价谁对谁错，但是我们可以向功夫巨星李小龙学习，博取百家之长，融汇贯通，开宗立派。文章后面所诉所讲几乎全是前人之总结、经验，并夹杂部分我个人粗劣的见解。虽可能会过于片面，但却希望能抛砖引玉，给诸君一些启发，引起部分共鸣。本编文章的编写借鉴了Robert C.Martin的很多思想和看法，在此表示由衷的感谢和敬仰之情。下面是部分程序员对代码整洁之道的理解，现分享如下：

  我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少代码依赖，使之便于维护；依据某种分层思想完善错误处理代码；性能调至最优，避免引诱别人做出没规矩的优化，搞出混乱来。每个函数、每个类和每个模块都全神贯注于一件事，完全不受四周细节的干扰和污染。

                                                                              ---------Bjarne Stroustrup

  整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直接了当的控制语句。

                                                                              ---------Grady Booch

  整洁的代码总是看起来像是某位特别在意它的人写的，几乎没有改进的余地。代码的作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给你的代码------全身心的投入到某人留下的代码。

                                                                             -----------Michael Feathers

2 好的命名

  程序中的命名随处可见，变量、函数和参数等。好的命名能够让新手更好更快的了解你的代码，对你的代码功能和实现逻辑一目了然。

2.1 名副其实

  当一个新手拿到这份代码，通过变量、参数和函数就能够知道它为什么存在、做什么事、应该怎么用，如果需要额外的注释才能达到以上效果，那就不是名副其实。而且在代码的修改和维护过程中，如果发现更好的名称，一定要换掉旧的。这种做法无论是你本人还是对你代码的人都会非常的高兴。

2.2 避免误导

  两个命名之间如果只是有细微的差别，往往会对阅读者产生误导，使阅读者无法明确到底使用哪个函数，如下函数，你能确定各函数间的差别吗。如果你的程序中出现以下情况，你就应当考虑它们之间是否有什么关联之处，是否可以合而为一。

2.3 名字最好能够读的出来

  程序不仅仅是用来修改，修改的过程中往往伴随着交流。如果你的命令别人无法读出，实在是中耻辱。大家可以对比一下下面两段代码：

  void DataRcrd102(void)

  {

    uint32 genymdhms;

    uint32 modymdhms;

    uint8 pszqint = 102;

  }

  和

  void Customer(void)

  {

    uint32 generationTimestamp;

    uint32 modificationTimestamp;

    uint8 recordId = 102;

  }

  然后就可以听到下面的对话了:"hi,辛工，生成时间戳（generation Timestamp）怎么没有被设置啊！什么原因？"

2.4 避免思维映射

  不能让读者将你的命名错误的理解成他们习惯的言语，也不能单纯的以你的个人喜好随意命名。在命名的时候你需要明确，你不是为了体现你的幽默才去命名，也不是为了体现你的才华才去命名，你的首要任务是让别人理解你的命名。明确才是王道，宁可明确，勿为好玩。言到意到，意到言到。

2.5 从一而终

  函数名是独一无二的，但是对于同一个变量、参数，在不同的函数内部的命名要追求一致，避免将同一个单词用于不同的用途，要遵循“一词一义”的原则。试想一下，如果在两个函数中，分别出现controllers和managers，会不会让人联想到，他们到底有什么不同呢？如果相同，为什么又用两个不同的词汇呢？对于阅读你代码的人来说，一以贯之的命名简直是天降福音。

2.6 语境

  很少有名词能够自我说明，如name、street、city和country，把他们联系到一起可以组成一个地址，但是当他们中的单独一个出现在程序中的某一处的时候，你是否会联想到它是某个地址的一部分？当然把他们封装成一个对象是一种很好的解决办法。但是还有一种办法就是在命名的时候为它们提供一种语境，比如在前面所有的命名前面加上address，你是不是就知道他们是某个地址的一部分了。

3 函数

  写代码和写散文一样，我们不可能一开始就能写的十分完美，总是需要反复的打磨。写函数时也是一样，一开始可能只是为了实现其基本的功能，函数写的丑陋不堪。然后按照下面的规则打磨代码，分解函数、修改名称，消除重复，同时保持功能测试通过。我们不可能一开始就能严格按照规则敲打代码，我想也没人做的到。

3.1 短小

  函数的第一规则就是短小，第二条规则就是更加的短小。个人认为每个函数20行封顶最佳。

3.2 只做一件事

  函数应该做一件事。做好这件事，只做一件事。要判断函数是否不止做了一件事，就是看它是否能再拆出一个函数。只做一件事的函数无法被合理的切分为多个区段。

3.3 每个函数都在一个抽象层级

  要确保函数只做一件事，函数中的语句都要在同一抽象层级上。否则会让可读性变差，让人不知道总的逻辑脉络。

3.4 函数命名

  好名称的价值怎么好评都不为过，多半工作都在为只做一件事的小函数取个好名字，函数越是短小、功能越集中，就越便于取个好名字。别害怕名字长，长而具有描述性的名称，要比短而令人费解的名称好，也要比描述性的注释好。指定某种命名约定，并始终坚持下去。

3.5 别重复自己

  同一段代码在多个不同的函数中重复出现，且与其它代码混在一起，而且也不完全一样。这样的重复使代码变得臃肿，而且当这段代码需要改变时，要同时修改多出，遗漏往往带来错误。重复是软件中一切邪恶的根源，我们要控制和消除重复。

4 注释

  曾几何时，我认为代码的可读性和注释的多少成正比。渐渐的我才明白，注释的真正功效是弥补我们编写代码时的失败。我们在编程中没有找到一种更好的表达方法，因此我们只能选择注释。为什么说注释是对失败的弥补，因为一份代码是在不断修改的，你不能保证每个修改者都能很好的修改注释，注释只会与代码渐行渐远，不会美化你那糟糕的代码。因此好的代码应该能够实现自注释，如果你编程的时候想要添加注释，那就说明该部分的程序需要重构。以下几种注释应当极力避免添加：

  （1）喃喃自语，除了你自己别人很难明白，明白注释话费的时间可能比阅读代码的时间还要长；

  （2）为了注释而注释，代码本身已经能明显的的说明问题，还要添加多余的注释；

  （3）每个模块、每个函数前的注释，这些注释在创建之初可能还算写实，但是随着时间的推移，这些记录可能会越来越凌乱不堪。因此这种注释太多，只能说明你的函数不够短小精悍，你的程序结构、逻辑不够条理清晰，当然也有可能是你不够自信；

  （4）为了标注代码中的某个特殊位置，使用特俗符号注释进行标记；

  （5）在一些嵌套函数的特殊括号的后面添加注释，只能说明你的函数还不够简练、分层还不够明显；

  （6）注释掉的代码一定要删除，因为后来者往往会怀疑这些注释掉的代码是不是有什么特殊的寓意，而你何尝不是后来者；

  （7）如果某些算法逻辑等，是在找不到好的表述方式，可以尝试添加注释，但是切忌信息过多、词不达意，确保它紧跟被描述程序的后面。

5 代码格式

  就像诗和散文一样，好的格式不止能够给人以美感，更有助于表达。你敲写的代码可能随着时间的推移不断被修改，直至消失。但是你的代码风格会被后来者延续下来。因此，可能不久的将来，你的代码早已不复存在，而你的风格和律条仍然存活下来。每个人都有自己的写作风格，但是一个工程是由多人配合完成。因此在你的团队开始工作之前，不妨一起讨论出一种格式风格，可能这并非是你喜爱的规则，但它是团队决定的规则，你就应该去遵守。个人认为有几下几点格式标准还是可以借鉴的：

  （1）一段程序中，不同概念的代码利用空白行隔开，使程序开起来一块一块的，而不是乱糟糟的一团。

  （2）功能、概念、关联相近的代码、函数应该在垂直方向上靠近，因为他们间可能会相互调用，你可能需要在这些函数间不停的切换，如果他们相距较远，或存在于不同的文件里，你将很难记住或弄明白他们间的相互联系。若某个函数调用了另一个函数，就应该尽可能的把他们放到一起，而且调用者应该尽可能的放在被调用者的上面；概念相关的代码就应该放在一起，相关性越强，彼此之间的距离就应该越短。

  （3）在水平方向上，每行代码上限最好不要超过120个字符，相关性较弱的事物利用空格分隔开来。

  （4）代码中学会使用缩进，合适的缩进能够让你对文件的结构一目了然。