作為 Java 開發(fā)人員攀操，我們會遵循一系列的編碼風格和開發(fā)習慣金矛。習慣使然是一方面，另一方面失驶，我們也從不停下腳步質(zhì)疑這些習慣土居。一段時間以后，筆者養(yǎng)成了一些不同于常人的編碼風格和開發(fā)習慣嬉探。當?shù)谝淮瘟私獾竭@些編碼風格時擦耀，筆者感到又驚又氣。但是涩堤，花了一段時間踐行這些習慣之后眷蜓，筆者意識到它們的確能造就更加簡潔可控的代碼庫，同時也讓開發(fā)者更加省心胎围。
不要因這些想法的另類而否定它們吁系，筆者建議你用幾周時間嘗試其中的一兩條，如果你仍然不喜歡它們白魂，換回以前的代碼風格也用不了多久時間汽纤。
零注釋（公共 API 除外）
筆者一度認為業(yè)內(nèi)對于零注釋這種編程習慣已經(jīng)達成共識，但是當與許多同事合作之后福荸，筆者發(fā)現(xiàn)事實并非如此蕴坪。所以，讓我們再次探討這個問題：無注釋敬锐。注釋很快就會與代碼脫節(jié)辞嗡。假如你在一段代碼的上面寫了行注釋，誰也不能保證下一個修改代碼的人會更新注釋滞造。根據(jù)筆者的開發(fā)經(jīng)驗续室，沒人會更新注釋。原來的代碼段可能被刪除谒养，業(yè)務需求也可能改變挺狰。因此明郭，你的注釋往往弊大于利。
對此丰泊，有個簡單的解決方案薯定，就是寫自記錄代碼（self documenting code）。對變量瞳购、對象或者函數(shù)等進行命名時话侄，選擇能清晰表達其用途的名字。假如不夠清晰学赛，你需要對它們進行重構年堆，將之拆分為更簡潔的形式。只要能直觀地表達其用途盏浇，過長的名字也無需擔憂变丧。別忘了編輯器有自動填寫功能，沒人需要敲出整個標識符的名字绢掰。
然而痒蓬，公共 API 是一個明顯的例外。假如你正在建立一個準備公開發(fā)版的庫滴劲，那還是使用簡潔的方法名比較好攻晒。不過， Javadoc 對這種情況大有裨益班挖，但也僅限此情況炎辨。
不要用 “Test” 為測試方法開頭
確實沒有必要這么做。你寫的方法會注釋為測試聪姿，方法所在的類也存在于測試包中碴萧。明眼人都知道那是測試。其實末购，測試方法名應該明確指出測試的內(nèi)容與條件破喻。例如， “reversesTheWordRandomToModnar()”或者“adds70ToBalanceOf100ToMakeBalanceOf170()”盟榴，這些名字都準確表達了測什么功能以及預期的結果曹质。
如果你正在使用 IntelliJ ，有一款特別棒的插件叫做 Enso 擎场。它可以將測試名轉(zhuǎn)化成一個句子羽德，一目了然地顯示測試的內(nèi)容。這意味著當你在注視任何類的時候迅办， Enso 都會展示其說明文檔宅静。
不要使用@Override
這個觀點爭議頗多，請聽筆者說完站欺。假如你不使用 @override 姨夹，最壞的結果就是你重寫了一個函數(shù)纤垂，而調(diào)用時執(zhí)行的卻是原版函數(shù)，而非重寫的版本磷账。值得慶幸的是峭沦，在測試驅(qū)動開發(fā)模式下，測試整段代碼時就會定位到這個 bug 逃糟。這讓 @Override 成了一段冗余的代碼吼鱼。顯然，冗余的代碼不僅沒有好處绰咽，還會讓人分心菇肃。因此，停止使用 @Override 剃诅，而依賴 TDD（測試驅(qū)動開發(fā)）巷送。
不要使用 getX()/setY() 這樣的函數(shù)名
這確實讓人不由得感到惱火驶忌。 getXXX 和 setXXX 這種命名方式是 Javabeans 時代的前朝遺物矛辕。而 JavaBeans 時代早已過去，這種命名方式也不再適用了付魔。后者讓代碼變得令人反感卻沒有帶來什么好處聊品。去掉 get／set 這類關鍵字有利于字段名稱的簡潔。例如几苍， car.engine() 函數(shù)將生成一個引擎對象翻屈，而 car.engine(new v8()) 將引擎設置為新的型號。如果需要讀取多層級內(nèi)的對象（例如：car.lights().frontLeft() 對比 car.getLights().getFrontLeft()）妻坝，前者依舊表達清晰而且代碼更加簡潔伸眶。這個編程習慣筆者一開始也很反對，后來逐漸改變了看法刽宪，現(xiàn)在非常熱衷這一風格厘贼。
可運行的代碼>高性能的代碼
這段內(nèi)容和代碼風格關系不大，而是更加泛泛而談圣拄。每次看到人們?yōu)榱艘粋€問題嘴秸，精雕細刻地設計解決方案，花費大量的時間庇谆，筆者都會感到不悅岳掐。其實，在最基本的層面上解決問題然后測試性能饭耳。十有八九串述，這類方案都是高速，可擴展或符合其他時髦概念的寞肖。相反剖煌，筆者經(jīng)巢酿校看到人們設計了一個復雜的緩存解決方案，結果沒有提高性能卻把代碼弄成一團亂麻耕姊。解決問題時桶唐，先實施你能采取的最基本方案，然后再進行優(yōu)化茉兰。最起碼尤泽，這種方式能讓你有實例證明問題已經(jīng)解決。
使用自己的異常類型
筆者又一次錯誤地認為這一開發(fā)習慣是業(yè)內(nèi)的共識规脸。 Java 中的檢查性異常 （Checked exceptions） 很糟糕坯约，幾乎所有其他編程語言（例如C＃）都意識到了這一點，所以它們甚至沒有這個類型莫鸭。在筆者編寫的任何應用程序中闹丐，都會創(chuàng)建自己的異常類型，在這些應用程序中拋出的任何異常都會用筆者創(chuàng)建的異常類接住被因，然后拋出運行時異常卿拴。這讓代碼更加整潔（筆者從未在程序中拋出大量 XXXException ），也意味著筆者能通過 log 追朔異常來自代碼的哪一部分或者這是完全出乎意料的異常類型梨与。
（編譯自：https://dzone.com/articles/upgrade-your-code-conventions-2）
OneAPM 為您提供端到端的 Java 應用性能解決方案堕花，我們支持所有常見的 Java 框架及應用服務器，助您快速發(fā)現(xiàn)系統(tǒng)瓶頸粥鞋，定位異常根本原因缘挽。分鐘級部署，即刻體驗呻粹，Java 監(jiān)控從來沒有如此簡單壕曼。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客等浊。
本文轉(zhuǎn)自 OneAPM 官方博客
