[[82835]]

import類，而不是import整個包

在很多語言里，這通常是一種被推薦的做法，有些甚至是必須的。如果是在C++里，這還算是有點意義，因為更少 #include 意味著更快的編譯速度，然而，這種意義僅體現在需要花很長時間去編譯的大型項目中。

而對很多像Java這樣的語言，這毫無意義。因為它不影響編譯的時間，所有你得到的回報只是花更多的努力來維護你的import語句。雖然IDE可以幫助你做這些事情，但你仍然需要時不時的多點幾次鼠標/鍵盤，在版本控制系統里多留幾條變更記錄，干擾你的代碼審查。有什么實際用處？向官僚機構表明代碼很規范，無它用途。

面向接口編程

這項編程法則要求程序員定義接口，并針對接口來編程，而不是針對實現編程。理由非常簡單：容易開發第二種實現，易于測試(真的嗎？)，更有效的使用代碼。

問題就出在你不能凡事都按照這個原則。我個人認為，如果一個方法需要有多個實現，那使用接口是不二選擇。但除此之外，如果你仍遵守的話，除了增加代碼量，增添麻煩外，不會有任何好處。而且，把一個類重構成接口和它的實現并不困難，事實上是非常簡單，所以，為什么一開始就要寫接口呢，當需要時把它改造成接口也不晚。

禁用某種語言功能

在很多企業、組織使用的編碼規范中，你會發現各種各樣的類似于“不要使用goto語句”，“不要使用三元操作符”等規則。

如果一種語言的某種語法并未標志為“deprecated”，為什么不讓人使用？當然，要正確的使用！即使像 goto 這樣的語法同樣可以讓代碼更可讀、更易理解——只要你能以正確的方式、用在正確的地方。

使用Setters/getters，禁止public屬性

這是***的Java風格，Java里任何公有屬性都是不提倡的，任何屬性都應該通過 setters 和 getters 操作，不允許有任何質疑。有些共用框架更加強化了這些。每次當我看到一個5年前的老類里只有一些私有屬性和公有的無聊的 setters 和 getters ，我都會奇怪這是要干嘛？是為了增加代碼量？是為了預防將來有可能出現意外的屬性值修改？但是如果真的有人修改了，這又能起到什么預防效果？

單個返回語句

有人說多個返回語句會讓代碼變復雜。我發現卻正好完全相反。當方法/函數在退出之前需要做一些收尾工作時，單一return語句會讓函數更簡單，但在其它很多情況下，這反而會讓事情變得復雜，你需要添加額外的if-else來處理各種非正常退出情況。

盡量責任分離

我這里主要是針對“盡量”。有些人把這做到了極限，甚至有些變態。沒錯，把大的復雜的問題拆分成小的簡單問題，這很好。但拆的太小就會引起新的問題。如果你把一棵樹砍成牙簽那么大小的塊，你得到的就是一堆垃圾。

有些問題本身就是很復雜，你無法通過拆解來讓它變簡單。

為了讓這篇文章有個比較積極的結尾，下面是我認為的放之四海皆準的***實踐方法：

• 做任何事情都要有個理由
• 如果你做的未能符合預期，重做，替換方法或給予修正
• 扔掉垃圾通常是你最應該做的事情——不論這垃圾造價多高

英文原文：Programming best practices I disaprove

譯文鏈接：http://www.aqee.net/programming-best-practices-i-disaprove/