原文地址：https://dzone.com/articles/upgrade-your-code-conventions-2
譯文來(lái)自：OneAPM
作為Java開發(fā)人員，我們會(huì)遵循一系列的編碼風(fēng)格和開發(fā)習(xí)慣。習(xí)慣使然是一方面，另一方面，我們也從不停下腳步質(zhì)疑這些習(xí)慣。一段時(shí)間以后，筆者養(yǎng)成了一些不同于常人的編碼風(fēng)格和開發(fā)習(xí)慣。當(dāng)?shù)谝淮瘟私獾竭@些編碼風(fēng)格時(shí)，筆者感到又驚又氣。但是，花了一段時(shí)間踐行這些習(xí)慣之后，筆者意識(shí)到它們的確能造就更加簡(jiǎn)潔可控的代碼庫(kù)，同時(shí)也讓開發(fā)者更加省心。

不要因這些想法的另類而否定它們，筆者建議你用幾周時(shí)間嘗試其中的一兩條，如果你仍然不喜歡它們，換回以前的代碼風(fēng)格也用不了多久時(shí)間。

零注釋（公共 API 除外）
筆者一度認(rèn)為業(yè)內(nèi)對(duì)于零注釋這種編程習(xí)慣已經(jīng)達(dá)成共識(shí)，但是當(dāng)與許多同事合作之后，筆者發(fā)現(xiàn)事實(shí)并非如此。所以，讓我們?cè)俅翁接戇@個(gè)問題：無(wú)注釋。注釋很快就會(huì)與代碼脫節(jié)。假如你在一段代碼的上面寫了行注釋，誰(shuí)也不能保證下一個(gè)修改代碼的人會(huì)更新注釋。根據(jù)筆者的開發(fā)經(jīng)驗(yàn)，沒人會(huì)更新注釋。原來(lái)的代碼段可能被刪除，業(yè)務(wù)需求也可能改變。因此，你的注釋往往弊大于利。

對(duì)此，有個(gè)簡(jiǎn)單的解決方案，就是寫自記錄代碼（self documenting code）。對(duì)變量、對(duì)象或者函數(shù)等進(jìn)行命名時(shí)，選擇能清晰表達(dá)其用途的名字。假如不夠清晰，你需要對(duì)它們進(jìn)行重構(gòu)，將之拆分為更簡(jiǎn)潔的形式。只要能直觀地表達(dá)其用途，過(guò)長(zhǎng)的名字也無(wú)需擔(dān)憂。別忘了編輯器有自動(dòng)填寫功能，沒人需要敲出整個(gè)標(biāo)識(shí)符的名字。

然而，公共API是一個(gè)明顯的例外。假如你正在建立一個(gè)準(zhǔn)備公開發(fā)版的庫(kù)，那還是使用簡(jiǎn)潔的方法名比較好。不過(guò)， Javadoc對(duì)這種情況大有裨益，但也僅限此情況。

不要用 “Test” 為測(cè)試方法開頭
確實(shí)沒有必要這么做。你寫的方法會(huì)注釋為測(cè)試，方法所在的類也存在于測(cè)試包中。明眼人都知道那是測(cè)試。其實(shí)，測(cè)試方法名應(yīng)該明確指出測(cè)試的內(nèi)容與條件。例如， “reversesTheWordRandomToModnar()”或者“adds70ToBalanceOf100ToMakeBalanceOf170()”，這些名字都準(zhǔn)確表達(dá)了測(cè)什么功能以及預(yù)期的結(jié)果。

如果你正在使用 IntelliJ ，有一款特別棒的插件叫做 Enso 。它可以將測(cè)試名轉(zhuǎn)化成一個(gè)句子，一目了然地顯示測(cè)試的內(nèi)容。這意味著當(dāng)你在注視任何類的時(shí)候， Enso 都會(huì)展示其說(shuō)明文檔。

不要使用@Override
這個(gè)觀點(diǎn)爭(zhēng)議頗多，請(qǐng)聽筆者說(shuō)完。假如你不使用 @override ，最壞的結(jié)果就是你重寫了一個(gè)函數(shù)，而調(diào)用時(shí)執(zhí)行的卻是原版函數(shù)，而非重寫的版本。值得慶幸的是，在測(cè)試驅(qū)動(dòng)開發(fā)模式下，測(cè)試整段代碼時(shí)就會(huì)定位到這個(gè) bug 。這讓 @Override 成了一段冗余的代碼。顯然，冗余的代碼不僅沒有好處，還會(huì)讓人分心。因此，停止使用 @Override ，而依賴 TDD（測(cè)試驅(qū)動(dòng)開發(fā)）。

不要使用 getX()/setY() 這樣的函數(shù)名
這確實(shí)讓人不由得感到惱火。 getXXX 和 setXXX 這種命名方式是 Javabeans 時(shí)代的前朝遺物。而 JavaBeans 時(shí)代早已過(guò)去，這種命名方式也不再適用了。后者讓代碼變得令人反感卻沒有帶來(lái)什么好處。去掉 get／set 這類關(guān)鍵字有利于字段名稱的簡(jiǎn)潔。例如， car.engine() 函數(shù)將生成一個(gè)引擎對(duì)象，而 car.engine(new v8()) 將引擎設(shè)置為新的型號(hào)。如果需要讀取多層級(jí)內(nèi)的對(duì)象（例如：car.lights().frontLeft() 對(duì)比 car.getLights().getFrontLeft()），前者依舊表達(dá)清晰而且代碼更加簡(jiǎn)潔。這個(gè)編程習(xí)慣筆者一開始也很反對(duì)，后來(lái)逐漸改變了看法，現(xiàn)在非常熱衷這一風(fēng)格。

可運(yùn)行的代碼>高性能的代碼
這段內(nèi)容和代碼風(fēng)格關(guān)系不大，而是更加泛泛而談。每次看到人們?yōu)榱艘粋€(gè)問題，精雕細(xì)刻地設(shè)計(jì)解決方案，花費(fèi)大量的時(shí)間，筆者都會(huì)感到不悅。其實(shí)，在最基本的層面上解決問題然后測(cè)試性能。十有八九，這類方案都是高速，可擴(kuò)展或符合其他時(shí)髦概念的。相反，筆者經(jīng)常看到人們?cè)O(shè)計(jì)了一個(gè)復(fù)雜的緩存解決方案，結(jié)果沒有提高性能卻把代碼弄成一團(tuán)亂麻。解決問題時(shí)，先實(shí)施你能采取的最基本方案，然后再進(jìn)行優(yōu)化。最起碼，這種方式能讓你有實(shí)例證明問題已經(jīng)解決。

使用自己的異常類型
筆者又一次錯(cuò)誤地認(rèn)為這一開發(fā)習(xí)慣是業(yè)內(nèi)的共識(shí)。 Java 中的檢查性異常 （Checked exceptions） 很糟糕，幾乎所有其他編程語(yǔ)言（例如C＃）都意識(shí)到了這一點(diǎn)，所以它們甚至沒有這個(gè)類型。在筆者編寫的任何應(yīng)用程序中，都會(huì)創(chuàng)建自己的異常類型，在這些應(yīng)用程序中拋出的任何異常都會(huì)用筆者創(chuàng)建的異常類接住，然后拋出運(yùn)行時(shí)異常。這讓代碼更加整潔（筆者從未在程序中拋出大量 XXXException ），也意味著筆者能通過(guò) log 追朔異常來(lái)自代碼的哪一部分或者這是完全出乎意料的異常類型。