什么是整洁代码？不同的人会站在不同的角度阐述不同的说法。而我最喜欢的是Grady Booch（《面向对象分析与设计》作者）阐述：
"整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。"
整洁的代码就是一种简约（简单而不过于太简单）的设计，阅读代码的人能很清晰的明白这里在干什么，而不是隐涩难懂，整洁的代码读起来让人感觉到就像阅读散文-艺术的沉淀，作者是精心在意缔造出来。
一：命名
命名包括变量、函数、参数，类等，一个好的命名能够很好的表述其所承载的业务，从命名上就已经很好的答复了为什么存在，做了什么事，应该怎么用等的大部分的问题，阅读者看到它的时候不必去深究其实现细节，一切都在命名上一目了然。一个好的命名必须是名副其实，不存在歧义（双关语或常见属于冲突），直接了当（否定语句或者误导性命名）。
二：函数
从汇编/C时代开始的到现在函数一直都存在与我们开发中不可或缺的一部分，结构化组织，重用。作为函数式语言的一等公民，所有程序的第一组代码。
好的函数必须足够的小，其次还是足够的小。很容易想像阅读上千行的代码，是多么巨大的自我心理挑战，在实习的时候工作于毫无分层逻辑的WinForm平台下，完全依赖RAD模式带来后置cs页面上千行的代码，每次修改都令我恼怒，恨不得重写整个业务逻辑。
一个函数在于短小精悍，只作一件事情，并做好这件事，只做一件事才能得到更好的利用函数名表述自己。
好的函数还应该是CQS（查询命令分离）无副作用的（不存在隐藏歧义的背后逻辑），并对其他类型不存在"依恋情节（Feature Envy）"（类中的变量被所有的函数使用这是理想的高内聚，万物皆有其位，而后物尽归其位）。
函数的参数应该足够的少，无最好，一次之，再次为二，尽量避免三个以及三个以上，对于太多的参数你可能该采用IntroduceParameterObject（引入参数对象）。
重复的代码。重复在软件系统是万恶的，我们熟悉的分离关注点，面向对象，设计原则…都是为了减少重复提高重用，Dont repeat yourself!（DRY）。
三：注释、格式
并不是写出完备的注释就是好的开发人员，如果代码清晰的表述自己意图，那么注释反而多余。在《重构-改善现有代码之道》中Martin Fowler指出多余的注释是一种代码坏味道。就是好的注释随着项目的维护不断的重构很多时候也会变得不那么适应，而我们很少会去主动维护。再则误导性的注释更为使用者所憎恨。当然有时我们也得使用注释，注释并不是万恶的，当我们没法用代码来描述自己的时候，我们需要注释去描述意图；多余有副作用的代码给使用者提供警告注释。TODO开发时进度控制，比如你在进行较大规模领域重构，目前有些逻辑不再适应，不那么自然，而对它的重构还在任务列表最后，你可以选择标注在TODO中，最后完成从ToDoList中去掉每一个TODO任务。
良好的代码格式，会使得我们阅读更容易，一套共同的格式会让我们查找理解更快速。每个团队都应该遵循一套固定的代码格式规范，整个软件系统的统风格统一，而不是各自为政各成一体。
四：对象和数据结构
数据结构指的就是数据的载体，暴露数据，而几乎没有有意义的行为的贫血类。最常见的应用在分布式服务，以wcf,webservice,reset之类的分布式服务中不可或缺的数据传输对象（DTO）模式，DTO（Request/Response）就是一个很典型的数据载体，只存在简单的get,set属性，并且更倾向于作为值对象存在。而对象则刚好相反作为面向对象的产物，必须封装隐藏数据，而暴露出行为接口，DDD中领域模型倾向于对象不仅在数据更多暴露行为操作自己或者关联状态。
数据结构和对象之间看是细微的差别却导致了不同的本质区别：使用数据结构的代码便于在不改动现在数据结构的前提下添加新的行为（函数），面向对象代码则便于不改动现 有函数的前提下添加新的类。换句话说就是数据结构难以添加新的的数据类型，因为需要改动所有函数，面向对象的代码则难以添加新的函数，因为需要修改所有的类。在任何一个复杂的系统都会同时存在数据结构和对象，我们需要判断的是我们需要的是需要添加的新的数据类型还是新的行为函数。
隐藏作为面向对象主要特性中的最重要特性，封装隐藏是面向对象中最重要的特性，一个好的面向对象代码肯定是对对象的内部细节做到很好的隐藏封装，封装过后才有是多态，委派之类的。一个好的面向对象的代码一定是具有很好的隐藏封装，易于测试，不稳定因素往往集中在一处很小或者固定的位置，不稳定因素的变更不会导致更大面积的修改扩散。
对象的隐藏要求：方法不应和任何调用方法返回的对象操作，换句话之和朋友说话，不和陌生人说话（迪米特法则，或被译为最小知识原则），比如：ctxt.getOptions（）。getSearchDir（）。getAbsolutePath（），就是迪米特法则的反例模式。
五：异常处理
每个软件系统都避不开异常处理，需要防止它搞乱我们的逻辑。
利用异常处理代替返回异常编码，返回异常编码会是的代码中充满了if/else,switch/case扰乱我的代码流转。
对于特定异常扑捉，可以面向异常编程，编写特定的异常类，使得对异常封装转化，更容易捕善后获处理。
避免返回null,在软件系统中最常见头疼的就是NullReferenceException.在非特定场景下，我们应该极力的避免返回null.面对这种场景我们可以采用null object Pattern（空对象模式）返回特例对象，如c#类库中的Guid.Empty,string.Empty;对于集合类型我们可以返回长度0的空集合而非null;
