原文地址：http://blog.csdn.net/u011700281/article/details/21623919
一、不要使用魔法数字，尽量定义枚举、常量、宏：
我常常见到表示各种状态的数字，0，1，2….，我真的不知道这表示什么含义，如果
你在不在文档中说明的话，这个东东过几天连你自己都不知道个一二三了。
二、命名要具有描述力，尽量使用全名而不是自创的缩写，除非地球人都这么用这个缩写：
我常常看到一些自创的缩写，这个缩写或许只有你自己知道，类名，方法名，参数名
尤其要有好的描述里，局部变量尚可容忍。我宁可容忍超过40个字符的命令，也不愿意
看到只有一两个字母的命名，当然迭代用的i,j除外。当然命名不要太长，太长说明你的类和
方法要做的事情太多，请你拆分出更多细粒度功能单一的类和方法。
三、同一类东东命名方式尽可能统一，比如类名使用大写字母开头的单词，变量使用
下划线分割开来的小写字母单词，常量使用下滑线分割的开来的大写字母单词。不要
交替使用。
四、函数、类功能尽可能单一，不要试图写一个万能/超级函数或者类。
一个类和方法要有单一的职责，这样的类和方法只做一件事，并且容易把他做好。
1、不要试图写一个强大无比的方法。
我常常看到一些试图写的多么“精妙”无比多么“强大”的函数，事实上不是什么精妙，而是
代码的臭味道。精妙强大无比万能的方法往往你耗费大量精力去设计算法，试图覆盖现在的各
种可能，而无法面对将来新的需求，随着新的需求，你的这个精妙的方法需要的修改并且改起来
极其痛苦。在一次次的痛苦与精妙的演化中，你的方法越来越复杂，并且每一次修改你都会面
临影响以前功能的风险。这个方法使用者需要小心的处理你的精妙之处，如果没有精妙传递好参
数，那么这个方法再也不精妙了，而是直接废掉了。
KISS（keep it simple and stupid）原理就是这个道理，你要使你的代码尽可能简单，让人
看到有一目了然的清爽，而不是因为设计了一个精妙无比的万能方法而沾沾自喜。这里的简单不是
简洁的代名字。有时候简洁是那种传说的“精妙”的代码。
2、不要写做多件事情的方法和类，你做一件事情，你就写一个对应的方法，不要试图通过参数来判定各种情况，然后做事情，并且做的事情和你方法描述的不一致。当你发现你的方法名字想不出来好的名字了，或者要加or和and了，那么请你拆分出更多单一的方法。
不要举一些linux完成多种功能系统调用，这是*的，因为系统调用的数量是有限制的，它只有有限的空间来描述系统调用号和系统调用的映射表，不要在应用程序开发中效仿而误以为优雅强大。我最恶心根据参数，然后一大堆的if..else 和switch..case判断。
五、不要修改已有的类和方法而是扩展它。
这是程序设计的一个重要原则，开闭原则，在面向对象的语言中尤为重要。在面向过程中主要表现在，不要在一个函数要应对和这个函数相似的一个需求了，就在这个加个if，来修改这个方法，试图重用和避免重复。而是要把公用的部分抽出来成一个小的功能函数，然后增加一个应对新的类似这个需求的处理方法。在面向对象中，例如使用策略模式、访问者模式、Extend Object模式。
六、不要重复你自己（DRY）：
程序最怕的是copy,paste，到处是重复的代码。copy，paste经常被误以为快速完成需要用的功能的高效方式而被到处使用。你每重复一次，你就得负责保持他们的一致性，你就得在一处增加新的功能时，你就的把这个的功能加到其他地方。还在我刚会写代码的时候去了一个小公司，他们的代码到处是copy，paste的痕迹，当要在现有的功能增加审计功能是，他们开始下命令了，每个人加几行代码来做审计，真不知道那么多人写的审计版本，分散到那么多处，这个审计功能是否可信有用。
避免DRY的方法就是抽象，分离变化。不管是面向对象还是面向过程，分离变化并抽象之是最主要的设计原则。设计模式中的模板方法，我们常用的回调都是我们常用的方法。
我发现越是提供更多回调处理的语言和框架，就越具有灵活性和易用性。ruby语言之所以有如此的威力，主要是因为它提供了更多的回调处理。它可以在动态的给一个类增加方法，这样可以在超类中定义增加方法的方法，然后再子类调用，子类就具有无比的能力。它的block提供了强大的回调机制，我只要不知道如何处理了我就yield出来，method missing机制更是神秘无比，你可以写出像find_by_name_and_age,2.days.ago这样像自然语言一样易读的代码。
七、不要跨越边界，在适合的地方写代码。
在分层的架构中，不要跨越层的边界。例如web开发的三层架构:
数据访问层（DAO)、业务层(Service)、表现层。
不要在业务层裸写SQL来做事情，不要在业务层掺和进来表现层的东东，不要在表现层/控制器中写业务的东东。既然已经分层了，那么就要好好的遵守它，如果到处跨越边界的话，那么和不分层没有什么区别，使得每一层都不伦不类。例如你应该在业务层进行事务管理，而你的控制器到处是业务代码，那将无法控制。如果你的业务层到处是SQL，我不知道你的DAO存在的意义了。
八、分层的web架构：
DAO层最好按照模型来划分dao类，如果业务很简单，也可以将相关的模型合并为一个DAO。
Service层，不要按照DAO和Service一一对应的方式划分，而是要按照业务的类别和实际情况来划分。事实上Service层通常是用来处理涉及到多个模型的业务，而涉及到一个模型的业务，常常被放在模型中，这是一种自然而更面向对象的设计方法。只有数据的模型被称为贫血型模型，这种模型被认为是对面向对象的一种背离，而在模型中放置专有的业务方法，不仅有利于公用，而且模型更具有描述力。
九、关于MVC:
MVC是一种松耦合的设计方案，最容易误用的就是控制器（c）。控制器只负责调用业务方法，准备好数据供View去展现。而不要把业务和如何展示的东东放在里面。我常常看到有人在控制器中拼html片段和写一些业务相关的代码。
十、顺便说一下异常的使用。
如果你是使用语言支持异常机制，那么尽可能的使用异常机制和定义好与自己业务相关的异常，而不是通过返回值表示正确和错误。如果你使用的语言支持异常机制，请不要写类linux下c似的代码形式，每写一个函数，我就写一个判断返回值调用是否成功，严重分离了我对核心业务的关注。异常提供了优雅的处理错误的方法。