是否曾經(jīng)瀏覽過別人的代碼，然后對自己說：“該死，這位程序員有風(fēng)格……”？我們不是在談?wù)揅SS，而是約定，方法和簡潔代碼的完美結(jié)合。

在編寫清晰易讀的代碼時，樣式具有重要作用。遵守約定和最佳做法是一個很好的起點。除此之外，還有大量的選擇余地。這些很大程度上取決于開發(fā)人員的級別和個人喜好。

約定和最佳實踐存在非常特殊的危險。他們中的大多數(shù)都是從該行業(yè)中摘錄的經(jīng)驗，并且有充分的理由在那里。其中一些可能令人懷疑，但很少（如果曾經(jīng)有過）受到質(zhì)疑。它們被并入了編碼風(fēng)格，并且沒有意識地指出它們變得不可見。我認為所有開發(fā)人員都應(yīng)不時調(diào)查其代碼，并檢查此類問題的最瑣碎元素。

我認為有幾件事值得研究：

getter / setter方法

因為IDE可以很容易地生成它們，所以它們經(jīng)常被濫用。一些開發(fā)人員習(xí)慣于立即生成它們，而無需進一步思考就丟棄了面向?qū)ο缶幊痰淖钪匾?封裝。變量是在可能不可變的對象上創(chuàng)建的。該get...()前綴是沒有意義的，實際上損害可讀性：

person.getName(); person.getAddress(); person.getMobileNumber();    person.name(); person.address(); person.mobileNumber();

常量命名約定

慣例是使用大寫的名稱，這可能非常難以理解–特別是在類中有許多長名稱常量的情況下。除非它是api的一部分，否則字段是常量的事實是實現(xiàn)細節(jié)。

局部變量的最終關(guān)鍵字

如果局部變量未分配為最終變量，則某些靜態(tài)代碼分析工具會顯示警告-如果它們僅被分配了一次。盡管它在某些特定情況下會增加價值，但如果無故將其應(yīng)用于所有局部變量，它帶來的混亂可能會使代碼難以閱讀。

可以說，在長而復(fù)雜的方法中嚴格使用它們是好的，那么問題首先就是復(fù)雜的方法。

異常后綴

這確實是一個有爭議的問題，但我認為至少值得考慮一下。幾乎所有例外...Exception的名稱中都有后綴。實際上，這實際上不是必需的，并且確實會增加一些噪音。請注意，在任何情況下，我們遇到異常時，語法都已經(jīng)很明顯：

• 異常的定義–某些東西擴展了異常

• 引發(fā)異常–引發(fā)新事物

• 拋出異常的聲明–拋出異常

• 捕獲異常– catch（某事）

刪除后綴可以處理被稱為事件的異常，而不僅僅是簡單的名詞–就其本身而言，這是一種有用的做法。比較FileNotFound與FileNotFoundException。在整個代碼庫中，基于事件的名稱和缺少后綴的應(yīng)用都會產(chǎn)生很好的效果。一些庫可以做到這一點，例如javassist，bouncycastle。

這些只是一些特定的示例，重要的部分是注意我們只是自動執(zhí)行的操作，并意識到我們這樣做的原因，以確保它們確實有意義。