import類，而不是import整個包
在很多語言裡，這通常是一種被推薦的做法，有些甚至是必須的。如果是在C++裡，這還算是有點意義，因為更少 #include 意味著更快的編譯速度，然而，這種意義僅體現在需要花很長時間去編譯的大型專案中。
而對很多像Java這樣的語言，這毫無意義。因為它不影響編譯的時間，所有你得到的回報只是花更多的努力來維護你的import語句。雖然IDE可以幫助你做這些事情，但你仍然需要時不時的多點幾次滑鼠/鍵盤，在版本控制系統裡多留幾條變更記錄，干擾你的程式碼審查。有什麼實際用處？向官僚機構表明程式碼很規範，無它用途。
面向介面程式設計
這項程式設計法則要求程式設計師定義介面，並針對介面來程式設計，而不是針對實現程式設計。理由非常簡單：容易開發第二種實現，易於測試(真的嗎？)，更有效的使用程式碼。
問題就出在你不能凡事都按照這個原則。我個人認為，如果一個方法需要有多個實現，那使用介面是不二選擇。但除此之外，如果你仍遵守的話，除了增加程式碼量，增添麻煩外，不會有任何好處。而且，把一個類重構成介面和它的實現並不困難，事實上是非常簡單，所以，為什麼一開始就要寫介面呢，當需要時把它改造成介面也不晚。
禁用某種語言功能
在很多企業、組織使用的編碼規範中，你會發現各種各樣的類似於“不要使用goto語句”，“不要使用三元操作符”等規則。
如果一種語言的某種語法並未標誌為“deprecated”，為什麼不讓人使用？當然，要正確的使用！即使像 goto 這樣的語法同樣可以讓程式碼更可讀、更易理解——只要你能以正確的方式、用在正確的地方。
使用Setters/getters，禁止public屬性
這是最著名的Java風格，Java裡任何公有屬性都是不提倡的，任何屬性都應該通過 setters 和 getters 操作，不允許有任何質疑。有些共用框架更加強化了這些。每次當我看到一個5年前的老類裡只有一些私有屬性和公有的無聊的 setters 和 getters ，我都會奇怪這是要幹嘛？是為了增加程式碼量？是為了預防將來有可能出現意外的屬性值修改？但是如果真的有人修改了，這又能起到什麼預防效果？
單個返回語句
有人說多個返回語句會讓程式碼變複雜。我發現卻正好完全相反。當方法/函式在退出之前需要做一些收尾工作時，單一return語句會讓函式更簡單，但在其它很多情況下，這反而會讓事情變得複雜，你需要新增額外的if-else來處理各種非正常退出情況。
儘量責任分離
我這裡主要是針對“儘量”。有些人把這做到了極限，甚至有些變態。沒錯，把大的複雜的問題拆分成小的簡單問題，這很好。但拆的太小就會引起新的問題。如果你把一棵樹砍成牙籤那麼大小的塊，你得到的就是一堆垃圾。
有些問題本身就是很複雜，你無法通過拆解來讓它變簡單。
為了讓這篇文章有個比較積極的結尾，下面是我認為的放之四海皆準的最佳實踐方法：
- 做任何事情都要有個理由
- 如果你做的未能符合預期，重做，替換方法或給予修正
- 扔掉垃圾通常是你最應該做的事情——不論這垃圾造價多高