[[82835]]

import類，而不是import整個包

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

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

面向接口編程

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

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

禁用某種語言功能

在很多企業(yè)、組織使用的編碼規(guī)范中，你會發(fā)現(xiàn)各種各樣的類似于“不要使用goto語句”，“不要使用三元操作符”等規(guī)則。

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

使用Setters/getters，禁止public屬性

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

單個返回語句

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

盡量責(zé)任分離

我這里主要是針對“盡量”。有些人把這做到了極限，甚至有些變態(tài)。沒錯，把大的復(fù)雜的問題拆分成小的簡單問題，這很好。但拆的太小就會引起新的問題。如果你把一棵樹砍成牙簽?zāi)敲创笮〉膲K，你得到的就是一堆垃圾。

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

為了讓這篇文章有個比較積極的結(jié)尾，下面是我認(rèn)為的放之四海皆準(zhǔn)的***實踐方法：

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

英文原文：Programming best practices I disaprove

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