整洁代码系列（1）

标签：优雅   美国   管理层   没有   行业   c++   程序员   des   对象   

1、首先我们必须要了解糟糕的代码会导致什么问题？

• 越糟糕的代码，别人理解的时间就越长，会导致进度严重滞后（代码不仅仅是写给自己看的，除了自己，团队的其他成员也需要在必要的时候去理解）；
• 越糟糕的代码，每次添加或修改代码，如果再不改变糟糕行为的前提下，代码回越来越烂，再也无法理清，最后会束手无策；
• 随着混乱的增加，团队的生产力会持续的下降，最后趋向于零。
• 当生产力下降时，管理层只会做一件事，就是增加更多的人手到项目中，期望提升生产力，可是新人并不熟悉系统的设计，但却背负着提升生产力的可怕压力，于是，有可能会知道出更多的混乱。

2、那什么是整洁的代码呢？是否有一定的标准呢？

这个是没有的，每个人都有自己整洁代码的标准呢，我们不妨可以来看看一些非常知名且经验丰富的程序员是怎么说的？

（1）我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。--Bjarne Stroustrup，C++语言发明者

　　（每个函数，每个类和每个模块都全神贯注于一件事，完全不受四周细节的干扰和污染）。

（2）整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。--Grady Booch，Object Oriented Analysis and Design with Applications（中译版《面向对象分析与设计》）一书作者。

 　　　　(代码应当讲述事实，不引人猜测，它只该包含必需之物。读者应当感受到我们的果断决绝)。

（3）整洁的代码应可由作者之外的开发者阅读和增补。它应当有单元测试和验收测试。它使用有意义的命名。它只提供一种而非多种做一件事的途径。它只有尽量少的依赖关系，而且要明确地定义和提供清晰、尽量少的API。代码应通过其字面表达含义，因为不同的语言导致并非所有必需信息均可通过代码自身清晰表达。 --Dave Thomas，OTI公司创始人，Eclipse战略教父

　　（增补一词，说明了整洁的代码要具有可扩展性；目前而言，测试驱动开发已经在行业中有深远影响，没有测试的代码是不干净的，不管它有多优雅、多可读、多易于理解，微于测试，其不洁亦可知道）。

（4）简单代码，依其重要顺序：

　　　　能通过所有测试；

　　　　　　没有重复代码；

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

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

　　　　　　----Ron Jeffries，Extreme Programming Installed（中译版《极限编程实施》）以及Extreme Programming Adventures in C#（中译版《C#极限编程探险》）作者。

　　　　　　（减少重复代码，提高表达力，提早构建简单抽象。这就是写整洁代码的方法）。

　　（5）如果每个例程都让你感到深合己意，那就是整洁代码。如果代码让编程语言看起来像是专为解决那个问题而存在，就可以称之为漂亮的代码。--Ward Cunningham，Wiki发明者，eXtreme Programming（极限编程）的创始人之一，Smalltalk语言和面向对象的思想领袖。所有在意代码者的教父。

　　　　　　（你可以想想最近一次看到深合己意的模块是什么时候，其实整洁的程序好到你根本不会注意到它，设计者把它做得像一切其他设计般简单）。

3、童子军军规

　　美国的童子军有一条简单的军规，就是“让营地比你来时更干净”，这完全可以应用到我们的专业领域：代码每次签入时，都要比签出时干净才行，这样子代码就不会腐坏，如果不能时时刻刻的保持代码整洁，随着时间的流逝，代码必将腐坏，因为不好的代码会“代代相传”（传说中的破窗效应）。

整洁代码系列（1）

标签：优雅   美国   管理层   没有   行业   c++   程序员   des   对象   

原文地址：http://www.cnblogs.com/Helius/p/6392313.html