红色部分为我对原文的批评语。
import类，而不是import整个包
在很多语言里，这通常是一种被推荐的做法，有些甚至是必须的。如果是在C++里，这还算是有点意义，因为更少 #include 意味着更快的编译速度，然而，这种意义仅体现在需要花很长时间去编译的大型项目中。
而对很多像Java这样的语言，这毫无意义。因为它不影响编译的时间（forlong401：错误言论，会影响编译的时间。详情参看：http://blog.csdn.net/forlong401/article/details/9956611），所有你得到的回报只是花更多的努力来维护你的import语句。虽然IDE可以帮助你做这些事情，但你仍然需要时不时的多点几次鼠标/键盘，在版本控制系统里多留几条变更记录，干扰你的代码审查。有什么实际用处？向官僚机构表明代码很规范，无它用途。
【
forlong401：
程序员可以使用两种import语句：
单类型导入(single-type-import)，例如import java.io.File;
按需类型导入(type-import-on-demand)，例如 import java.io.*;
查看JDK的源代码就知道SUN的软件工程师一般不会使用按需类型导入。因为使用单类型导入至少有以下两点好处：
1。提高编译速度。
2。避免命名冲突。(例如：当你import java.awt.*;import java.util.*后，使用List的时候编译器将会出编译错误)
当然，使用单类型导入会使用你的import语句看起来很长。
详情参看：http://blog.csdn.net/forlong401/article/details/9956611
】
面向接口编程
这项编程法则要求程序员定义接口，并针对接口来编程，而不是针对实现编程。理由非常简单：容易开发第二种实现，易于测试(真的吗？)，更有效的使用代码。
问题就出在你不能凡事都按照这个原则。我个人认为，如果一个方法需要有多个实现，那使用接口是不二选择。但除此之外，如果你仍遵守的话，除了增加代码量，增添麻烦外，不会有任何好处。而且，把一个类重构成接口和它的实现并不困难（forlong401：一个类简单，一千个呢？），事实上是非常简单，所以，为什么一开始就要写接口呢，当需要时把它改造成接口也不晚。（forlong401：几百万行代码，你以为改不花钱啊）
【
forlong401:
面向接口编程一般是架构师和系统设计师提倡，所以，可以推测原作者水平还比较低，而且是coder，很差的coder。
面向接口编程可以有如下好处：
1.更加抽象、更加面向对象。
2.提高编程的灵活性。
3.提高可维护性。
详细描述可参考：http://blog.csdn.net/forlong401/article/details/9956731
】
禁用某种语言功能
在很多企业、组织使用的编码规范中，你会发现各种各样的类似于“不要使用goto语句”，“不要使用三元操作符”等规则。
如果一种语言的某种语法并未标志为“deprecated”，为什么不让人使用？当然，要正确的使用！即使像 goto 这样的语法同样可以让代码更可读、更易理解——只要你能以正确的方式、用在正确的地方。
【
forlong401：
goto语法不让用是因为别人维护你的代码的时候，发现出口点太多了。不方便维护和调试。不知道是从那个地方跳出去了，又跳到哪里去了。就算你自己写的代码时间长了，或者工程庞大了，也不容易维护和调试。
】
使用Setters/getters，禁止public属性
这是最著名的Java风格，Java里任何公有属性都是不提倡的，任何属性都应该通过 setters 和 getters 操作，不允许有任何质疑。有些共用框架更加强化了这些。每次当我看到一个5年前的老类里只有一些私有属性和公有的无聊的 setters 和 getters ，我都会奇怪这是要干嘛？是为了增加代码量？是为了预防将来有可能出现意外的属性值修改？但是如果真的有人修改了，这又能起到什么预防效果？
【
forlong401：
setter方法
1.可以限制和检验setter方法传入的参数
2.隐藏对象内部数据结构
3.保持对象在每个状态的完整性
getter方法
1.按照客户的期望返回格式化数据
2.控制服务的顺序(例如只有当连接建立时getter方法才返回相应实例)
参考：http://stackoverflow.com/questions/7207994/java-setter-and-getter
框架中写的大部分getter和setter方法都是直接返回和赋值，不过实际上可以在方法中加入访问权限控制、逻辑判断等，实现OO编程中封装和信息隐藏。
好处：
1
将数据与行为分离，也就是java的面向对象的概念。
对象就是属性+行为，封装就是把对象的私有属性封装起来，只有通过自己公开的行为去改变（获得）对象内部的私有属性信息，而那些public的方法正是面向其他对象的接口，只有通过接口去改变（获得）对象的私有属性
2.安全性
3 编码规范性
5 可扩展性
6
便于维护
】
单个返回语句
有人说多个返回语句会让代码变复杂。我发现却正好完全相反。当方法/函数在退出之前需要做一些收尾工作时，单一return语句会让函数更简单，但在其它很多情况下，这反而会让事情变得复杂，你需要添加额外的if-else来处理各种非正常退出情况。
【
forlong401：
这个和goto原因类似，就不多说了。
】
尽量责任分离
我这里主要是针对“尽量”。有些人把这做到了极限，甚至有些变态。没错，把大的复杂的问题拆分成小的简单问题，这很好。但拆的太小就会引起新的问题。如果你把一棵树砍成牙签那么大小的块，你得到的就是一堆垃圾。
有些问题本身就是很复杂，你无法通过拆解来让它变简单。
为了让这篇文章有个比较积极的结尾，下面是我认为的放之四海皆准的最佳实践方法：
- 做任何事情都要有个理由
- 如果你做的未能符合预期，重做，替换方法或给予修正
- 扔掉垃圾通常是你最应该做的事情——不论这垃圾造价多高