import类，而不是import整个包
在很多语言里，这通常是一种被推荐的做法，有些甚至是必须的。如果是在C++里，这还算是有点意义，因为更少 #include 意味着更快的编译速度，然而，这种意义仅体现在需要花很长时间去编译的大型项目中。
而 对很多像Java这样的语言，这毫无意义。因为它不影响编译的时间，所有你得到的回报只是花更多的努力来维护你的import语句。虽然IDE可以帮助你 做这些事情，但你仍然需要时不时的多点几次鼠标/键盘，在版本控制系统里多留几条变更记录，干扰你的代码审查。有什么实际用处？向官僚机构表明代码很规 范，无它用途。
面向接口编程
这项编程法则要求程序员定义接口，并针对接口来编程，而不是针对实现编程。理由非常简单：容易开发第二种实现，易于测试(真的吗？)，更有效的使用代码。
问 题就出在你不能凡事都按照这个原则。我个人认为，如果一个方法需要有多个实现，那使用接口是不二选择。但除此之外，如果你仍遵守的话，除了增加代码量，增 添麻烦外，不会有任何好处。而且，把一个类重构成接口和它的实现并不困难，事实上是非常简单，所以，为什么一开始就要写接口呢，当需要时把它改造成接口也 不晚。
禁用某种语言功能
在很多企业、组织使用的编码规范中，你会发现各种各样的类似于“不要使用goto语句”，“不要使用三元操作符”等规则。
如果一种语言的某种语法并未标志为“deprecated”，为什么不让人使用？当然，要正确的使用！即使像 goto 这样的语法同样可以让代码更可读、更易理解——只要你能以正确的方式、用在正确的地方。
使用Setters/getters，禁止public属性
这 是最著名的Java风格，Java里任何公有属性都是不提倡的，任何属性都应该通过 setters 和 getters 操作，不允许有任何质疑。有些共用框架更加强化了这些。每次当我看到一个5年前的老类里只有一些私有属性和公有的无聊的 setters 和 getters ，我都会奇怪这是要干嘛？是为了增加代码量？是为了预防将来有可能出现意外的属性值修改？但是如果真的有人修改了，这又能起到什么预防效果？
单个返回语句
有人说多个返回语句会让代码变复杂。我发现却正好完全相反。当方法/函数在退出之前需要做一些收尾工作时，单一return语句会让函数更简单，但在其它很多情况下，这反而会让事情变得复杂，你需要添加额外的if-else来处理各种非正常退出情况。
尽量责任分离
我这里主要是针对“尽量”。有些人把这做到了极限，甚至有些变态。没错，把大的复杂的问题拆分成小的简单问题，这很好。但拆的太小就会引起新的问题。如果你把一棵树砍成牙签那么大小的块，你得到的就是一堆垃圾。
有些问题本身就是很复杂，你无法通过拆解来让它变简单。
为了让这篇文章有个比较积极的结尾，下面是我认为的放之四海皆准的最佳实践方法：
- 做任何事情都要有个理由
- 如果你做的未能符合预期，重做，替换方法或给予修正
- 扔掉垃圾通常是你最应该做的事情——不论这垃圾造价多高
引用来自“zhangzhikai”的评论
没看懂楼主的文章,不知道楼主是想反对那六个观点,还是支持?
引用来自“一线码农”的评论
同感呀，Java动不动就是接口，很多getter setter，一点都不简洁
引用来自“屈利春”的评论
蓝翔的学生又实习了吗?
引用来自“囫囵吞枣”的评论
虽然你貌似有足够的理由质疑最佳实践，Java本身也没有强制你必须那么做，但是没有这些约定，Java就不会产生Spring,Hibernate,Struts等优秀的框架，比如你反对getter/setter,按照你自己的风格行事，没有了getter/setter,你让Spring如何帮你注入依赖呢
引用来自“邓攀”的评论
谷歌没收购sun那一次很失败，orcale这个老狗，在开源方面比苹果还不要脸，苹果是敌视开源，orcale是买一个死一个
使用Setters/getters，禁止public属性
单个返回语句
认同。
有质疑才有进步，但这个老外在这里所质疑的都是Java的精髓。如果他了解下编程语言的发展历程，或者用过Fortain、C等过程语言，Delphi VB等早期的OO语言，那么他就了解为什么会有这些最佳实践了！
1. import类，而不是import整个包
VB和Delphi(2007之前）是没有包的，或者说只有一个默认的包，他们面临的一个问题是类名冲突。Java第一次完美解决了类名冲突问题（通过命名空间，即包名）。引入整个包，他是在冒着类名冲突的风险。
2 面向接口编程
面向接口编程是编程语言的一次具体进步。Ms Office是M$独家开发的，但他也使用了接口，而且为了解决接口与实现的问题，搞了一个非常丑陋的注册表，在导出一个Office报表的时候，谁也无法确定用户机器上安装了那个版本的Excel。
3 禁用某种语言功能
能力有限，还没有接触的他所说的这些禁区，无法对此评价
4.使用Setters/getters，禁止public属性
在C和Basic中，除了函数内部的变量，都是public的，都是全局的，正是因为放开字段有问题，才有了后来OO编程，强调对字段的封装。
Dephi，VB或者C++虽然强调封装，可方法（或者叫函数）命名没有任何可遵守的约定，而在Java中，封装字符使用getter/setter的确是Java的首创，也是Sun公司努力的结果，
正式在这些默认的约定基础上，Java开发者才能享受到Spring带来的便利，才有Hibernate，Struts等框架；Delphi、VB、C/C++等永远无法做到
5.单个返回语句 和 尽量责任分离
我认为这个没有什么问题。
Java不仅仅是一种编程语言，也是一种文化。这种文化很多情况就表现为约定，而不是靠语法来约束。就像走路，不但要有红绿灯的约束，还要有靠右边走及(行人/机动车)各行其道的约定。当然Java也不是万能的，如果感觉Java不趁手，可以考虑使用其他语言，比如Java的变种Ruby、Groovy等。
引用来自“風一樣的男子”的评论
引用来自“唐海康”的评论
引用来自“風一樣的男子”的评论
瞎扯
压根就不理解接口编程干嘛的
你要是涉及到远程调用啥的，难道你把实现类打包丢给调用者？
引用来自“chocotan”的评论
引用来自“艾皮狗”的评论
非常认同文章的观点，比如说那个"面向接口编程",真的是被滥用了。看看现在这些工程，调用一个service，首先是一个接口，然后是该接口的实现，接着又在里边调用dao接口，最后才是dao实现，而整个工程的service和dao接口都只有一个实现，却不得不写那么多无聊的接口，找代码也不方便，java本身就是一个语法很啰嗦的语言，这样一搞，开发效率就更低了
引用来自“_2kw”的评论
引用来自“貌似掉线”的评论
引用来自“_2kw”的评论
引用来自“貌似掉线”的评论
引用来自“_2kw”的评论
google编码规范里面 都是写着禁止哦。。。。
JB/dalvik/dexopt/OptMain.cpp
引用来自“貌似掉线”的评论
引用来自“_2kw”的评论
引用来自“貌似掉线”的评论
引用来自“_2kw”的评论
google编码规范里面 都是写着禁止哦。。。。
JB/dalvik/dexopt/OptMain.cpp
引用来自“_2kw”的评论
引用来自“貌似掉线”的评论
引用来自“_2kw”的评论
google编码规范里面 都是写着禁止哦。。。。
JB/dalvik/dexopt/OptMain.cpp
引用来自“貌似掉线”的评论
引用来自“_2kw”的评论
google编码规范里面 都是写着禁止哦。。。。
JB/dalvik/dexopt/OptMain.cpp
引用来自“唐海康”的评论
引用来自“風一樣的男子”的评论
瞎扯
压根就不理解接口编程干嘛的
你要是涉及到远程调用啥的，难道你把实现类打包丢给调用者？
引用来自“風一樣的男子”的评论
瞎扯
压根就不理解接口编程干嘛的
你要是涉及到远程调用啥的，难道你把实现类打包丢给调用者？
引用来自“囫囵吞枣”的评论
虽然你貌似有足够的理由质疑最佳实践，Java本身也没有强制你必须那么做，但是没有这些约定，Java就不会产生Spring,Hibernate,Struts等优秀的框架，比如你反对getter/setter,按照你自己的风格行事，没有了getter/setter,你让Spring如何帮你注入依赖呢
引用来自“貌似掉线”的评论
引用来自“starstroll”的评论
引用来自“崔钢”的评论
import类，而不是import整个包
对于java这样的语言来说，明确的引入类，可以提高编译的速度，当然这个不明显，也不是最重要的。关键是可以提高可读性。
面向接口编程
这个我也觉得意义不是很大，但是如果你需要使用spring，aop技术，多使用接口是好的。
禁用某种语言功能
goto语句问题我就不说了。这个真的没有必要。
使用Setters/getters，禁止public属性
这个东西是javabean规范，如果你需要使用某些框架，这个是很必要的。此外保护对象的内容，这个是封装的基本意识。。。。
尽量责任分离
这些原则，说说就行了，估计也难以做到极致。不如追求，简单明确。
AOP技术同样地降低代码可读性，少了几行代码缺在代码中隐藏了太多的陷阱。
goto说实话，如果if段落长的话，真不如goto逻辑来得清晰，存在必定合理。
同时存在getter/setter的属性有什么东西是被保护的？不同时存在getter/setter的属性还是占极少数，个人认为这个论点有一定道理。
凡事不能极端，必须有一个平衡点。
goto语句也在android源码中刚读到，在那代码里对goto的使用使代码一点也不失优雅。
引用来自“haitao”的评论
引用来自“風一樣的男子”的评论
引用来自“haitao”的评论
引用来自“風一樣的男子”的评论
瞎扯
压根就不理解接口编程干嘛的
你要是涉及到远程调用啥的，难道你把实现类打包丢给调用者？
好好理解再说
编程的本质是什么？
代码易理解，编写高效，运行高效，维护高效
引用来自“風一樣的男子”的评论
引用来自“haitao”的评论
引用来自“風一樣的男子”的评论
瞎扯
压根就不理解接口编程干嘛的
你要是涉及到远程调用啥的，难道你把实现类打包丢给调用者？
好好理解再说
编程的本质是什么？
代码易理解，编写高效，运行高效，维护高效
引用来自“starstroll”的评论
引用来自“崔钢”的评论
import类，而不是import整个包
对于java这样的语言来说，明确的引入类，可以提高编译的速度，当然这个不明显，也不是最重要的。关键是可以提高可读性。
面向接口编程
这个我也觉得意义不是很大，但是如果你需要使用spring，aop技术，多使用接口是好的。
禁用某种语言功能
goto语句问题我就不说了。这个真的没有必要。
使用Setters/getters，禁止public属性
这个东西是javabean规范，如果你需要使用某些框架，这个是很必要的。此外保护对象的内容，这个是封装的基本意识。。。。
尽量责任分离
这些原则，说说就行了，估计也难以做到极致。不如追求，简单明确。
AOP技术同样地降低代码可读性，少了几行代码缺在代码中隐藏了太多的陷阱。
goto说实话，如果if段落长的话，真不如goto逻辑来得清晰，存在必定合理。
同时存在getter/setter的属性有什么东西是被保护的？不同时存在getter/setter的属性还是占极少数，个人认为这个论点有一定道理。
凡事不能极端，必须有一个平衡点。
goto语句也在android源码中刚读到，在那代码里对goto的使用使代码一点也不失优雅。
引用来自“zengraoli”的评论
只看第2点----面向接口编程，只会多增加代码量
要不然，咱们多学学c？不要使用类，在main里面写入全部的方法？那样会不会减少很多的代码行？
第二，不使用类和面向接口编程没有什么直接的关系。盲目地使用接口并不代表它的反面就是不面向对象。
引用来自“_2kw”的评论
google编码规范里面 都是写着禁止哦。。。。
JB/dalvik/dexopt/OptMain.cpp
引用来自“1inus”的评论
引用来自“囫囵吞枣”的评论
虽然你貌似有足够的理由质疑最佳实践，Java本身也没有强制你必须那么做，但是没有这些约定，Java就不会产生Spring,Hibernate,Struts等优秀的框架，比如你反对getter/setter,按照你自己的风格行事，没有了getter/setter,你让Spring如何帮你注入依赖呢
引用来自“囫囵吞枣”的评论
虽然你貌似有足够的理由质疑最佳实践，Java本身也没有强制你必须那么做，但是没有这些约定，Java就不会产生Spring,Hibernate,Struts等优秀的框架，比如你反对getter/setter,按照你自己的风格行事，没有了getter/setter,你让Spring如何帮你注入依赖呢
引用来自“haitao”的评论
引用来自“風一樣的男子”的评论
瞎扯
压根就不理解接口编程干嘛的
你要是涉及到远程调用啥的，难道你把实现类打包丢给调用者？
好好理解再说
引用来自“蛋蛋为何忧伤”的评论
引用来自“starstroll”的评论
引用来自“工头叫我去搬砖”的评论
欧阳锋练九阴真经都能练出门道，小喽啰这样的话早死了；风清扬说剑法就一定要用剑吗，真气所至，草木皆为利刃，飞花落木亦可伤人，不认识他的人肯定认为风在放屁。层次不同看到的东西不同，所以在还没到这个层次前，还是老老实实按照师傅给的剑谱套路来吧
引用来自“starstroll”的评论
引用来自“工头叫我去搬砖”的评论
欧阳锋练九阴真经都能练出门道，小喽啰这样的话早死了；风清扬说剑法就一定要用剑吗，真气所至，草木皆为利刃，飞花落木亦可伤人，不认识他的人肯定认为风在放屁。层次不同看到的东西不同，所以在还没到这个层次前，还是老老实实按照师傅给的剑谱套路来吧
引用来自“chocotan”的评论
引用来自“艾皮狗”的评论
非常认同文章的观点，比如说那个"面向接口编程",真的是被滥用了。看看现在这些工程，调用一个service，首先是一个接口，然后是该接口的实现，接着又在里边调用dao接口，最后才是dao实现，而整个工程的service和dao接口都只有一个实现，却不得不写那么多无聊的接口，找代码也不方便，java本身就是一个语法很啰嗦的语言，这样一搞，开发效率就更低了
其他的大多是滥用，显然任何事情都得有个度
如果你把一棵树砍成牙签那么大小的块，你得到的就是一堆垃圾。
这个举例有点极端了，也许是我太钻牛角尖了。
brew upgrade macvim
引用来自“崔钢”的评论
import类，而不是import整个包
对于java这样的语言来说，明确的引入类，可以提高编译的速度，当然这个不明显，也不是最重要的。关键是可以提高可读性。
面向接口编程
这个我也觉得意义不是很大，但是如果你需要使用spring，aop技术，多使用接口是好的。
禁用某种语言功能
goto语句问题我就不说了。这个真的没有必要。
使用Setters/getters，禁止public属性
这个东西是javabean规范，如果你需要使用某些框架，这个是很必要的。此外保护对象的内容，这个是封装的基本意识。。。。
尽量责任分离
这些原则，说说就行了，估计也难以做到极致。不如追求，简单明确。
AOP技术同样地降低代码可读性，少了几行代码缺在代码中隐藏了太多的陷阱。
goto说实话，如果if段落长的话，真不如goto逻辑来得清晰，存在必定合理。
同时存在getter/setter的属性有什么东西是被保护的？不同时存在getter/setter的属性还是占极少数，个人认为这个论点有一定道理。
凡事不能极端，必须有一个平衡点。
引用来自“風一樣的男子”的评论
瞎扯
压根就不理解接口编程干嘛的
你要是涉及到远程调用啥的，难道你把实现类打包丢给调用者？
引用来自“工头叫我去搬砖”的评论
欧阳锋练九阴真经都能练出门道，小喽啰这样的话早死了；风清扬说剑法就一定要用剑吗，真气所至，草木皆为利刃，飞花落木亦可伤人，不认识他的人肯定认为风在放屁。层次不同看到的东西不同，所以在还没到这个层次前，还是老老实实按照师傅给的剑谱套路来吧
压根就不理解接口编程干嘛的
你要是涉及到远程调用啥的，难道你把实现类打包丢给调用者？
引用来自“艾皮狗”的评论
非常认同文章的观点，比如说那个"面向接口编程",真的是被滥用了。看看现在这些工程，调用一个service，首先是一个接口，然后是该接口的实现，接着又在里边调用dao接口，最后才是dao实现，而整个工程的service和dao接口都只有一个实现，却不得不写那么多无聊的接口，找代码也不方便，java本身就是一个语法很啰嗦的语言，这样一搞，开发效率就更低了
如果自己一个人或是2个人的工程代码，有些点确实比较适用，比如接口，set，get，public。但如果是一个team的工程，显然还是遵守规范才是第一位的。
这些都是老生常谈的问题，其实笔者更多的是在拿Java开刀，这些冗余的复杂不是一次两次进行这样的争论了。
但现在自己在写一些小工程的时候确实不再老老实实的写哪些接口，set，get什么规范之类的了。
对于java这样的语言来说，明确的引入类，可以提高编译的速度，当然这个不明显，也不是最重要的。关键是可以提高可读性。
面向接口编程
这个我也觉得意义不是很大，但是如果你需要使用spring，aop技术，多使用接口是好的。
禁用某种语言功能
goto语句问题我就不说了。这个真的没有必要。
使用Setters/getters，禁止public属性
这个东西是javabean规范，如果你需要使用某些框架，这个是很必要的。此外保护对象的内容，这个是封装的基本意识。。。。
尽量责任分离
这些原则，说说就行了，估计也难以做到极致。不如追求，简单明确。
其实很多人在骂get set，但是其实根本不知道为什么get set吧。
讨论的很多问题其实只是个"度"的问题
getter setter：只有1%的情况下，才需要在setter中增加额外的判断，而且这时候object已经不是简单的bean了。
getter/setter在框架里运作很好，但是自己写一些东西，完全没必要全部这样写
要不然，咱们多学学c？不要使用类，在main里面写入全部的方法？那样会不会减少很多的代码行？