升級 Java 編程規范的6個約定

作為 Java 開發人員,我們會遵循一系列的編碼風格和開發習慣。習慣使然是一方面,另一方面,我們也從不停下腳步質疑這些習慣。一段時間以后,筆者養成了一些不同于常人的編碼風格和開發習慣。當第一次了解到這些編碼風格時,筆者感到又驚又氣。但是,花了一段時間踐行這些習慣之后,筆者意識到它們的確能造就更加簡潔可控的代碼庫,同時也讓開發者更加省心。

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

零注釋(公共 API 除外)

筆者一度認為業內對于零注釋這種編程習慣已經達成共識,但是當與許多同事合作之后,筆者發現事實并非如此。所以,讓我們再次探討這個問題:無注釋。注釋很快就會與代碼脫節。假如你在一段代碼的上面寫了行注釋,誰也不能保證下一個修改代碼的人會更新注釋。根據筆者的開發經驗,沒人會更新注釋。原來的代碼段可能被刪除,業務需求也可能改變。因此,你的注釋往往弊大于利。

對此,有個簡單的解決方案,就是寫自記錄代碼(self documenting code)。對變量、對象或者函數等進行命名時,選擇能清晰表達其用途的名字。假如不夠清晰,你需要對它們進行重構,將之拆分為更簡潔的形式。只要能直觀地表達其用途,過長的名字也無需擔憂。別忘了編輯器有自動填寫功能,沒人需要敲出整個標識符的名字。

然而,公共 API 是一個明顯的例外。假如你正在建立一個準備公開發版的庫,那還是使用簡潔的方法名比較好。不過, Javadoc 對這種情況大有裨益,但也僅限此情況。

不要用 “Test” 為測試方法開頭

確實沒有必要這么做。你寫的方法會注釋為測試,方法所在的類也存在于測試包中。明眼人都知道那是測試。其實,測試方法名應該明確指出測試的內容與條件。例如, “reversesTheWordRandomToModnar()”或者“adds70ToBalanceOf100ToMakeBalanceOf170()”,這些名字都準確表達了測什么功能以及預期的結果。

如果你正在使用 IntelliJ ,有一款特別棒的插件叫做 Enso 。它可以將測試名轉化成一個句子,一目了然地顯示測試的內容。這意味著當你在注視任何類的時候, Enso 都會展示其說明文檔。

不要使用@Override

這個觀點爭議頗多,請聽筆者說完。假如你不使用 @override ,最壞的結果就是你重寫了一個函數,而調用時執行的卻是原版函數,而非重寫的版本。值得慶幸的是,在測試驅動開發模式下,測試整段代碼時就會定位到這個 bug 。這讓 @Override 成了一段冗余的代碼。顯然,冗余的代碼不僅沒有好處,還會讓人分心。因此,停止使用 @Override ,而依賴 TDD(測試驅動開發)。

不要使用 getX()/setY() 這樣的函數名

這確實讓人不由得感到惱火。 getXXX 和 setXXX 這種命名方式是 Javabeans 時代的前朝遺物。而 JavaBeans 時代早已過去,這種命名方式也不再適用了。后者讓代碼變得令人反感卻沒有帶來什么好處。去掉 get/set 這類關鍵字有利于字段名稱的簡潔。例如, car.engine() 函數將生成一個引擎對象,而 car.engine(new v8()) 將引擎設置為新的型號。如果需要讀取多層級內的對象(例如:car.lights().frontLeft() 對比 car.getLights().getFrontLeft()),前者依舊表達清晰而且代碼更加簡潔。這個編程習慣筆者一開始也很反對,后來逐漸改變了看法,現在非常熱衷這一風格。

可運行的代碼>高性能的代碼

這段內容和代碼風格關系不大,而是更加泛泛而談。每次看到人們為了一個問題,精雕細刻地設計解決方案,花費大量的時間,筆者都會感到不悅。其實,在最基本的層面上解決問題然后測試性能。十有八九,這類方案都是高速,可擴展或符合其他時髦概念的。相反,筆者經常看到人們設計了一個復雜的緩存解決方案,結果沒有提高性能卻把代碼弄成一團亂麻。解決問題時,先實施你能采取的最基本方案,然后再進行優化。最起碼,這種方式能讓你有實例證明問題已經解決。

使用自己的異常類型

筆者又一次錯誤地認為這一開發習慣是業內的共識。 Java 中的檢查性異常 (Checked exceptions) 很糟糕,幾乎所有其他編程語言(例如C#)都意識到了這一點,所以它們甚至沒有這個類型。在筆者編寫的任何應用程序中,都會創建自己的異常類型,在這些應用程序中拋出的任何異常都會用筆者創建的異常類接住,然后拋出運行時異常。這讓代碼更加整潔(筆者從未在程序中拋出大量 XXXException ),也意味著筆者能通過 log 追朔異常來自代碼的哪一部分或者這是完全出乎意料的異常類型。

(編譯自:https://dzone.com/articles/upgrade-your-code-conventions-2

OneAPM 為您提供端到端的 Java 應用性能解決方案,我們支持所有常見的 Java 框架及應用服務器,助您快速發現系統瓶頸,定位異常根本原因。分鐘級部署,即刻體驗,Java 監控從來沒有如此簡單。想閱讀更多技術文章,請訪問 OneAPM 官方技術博客
本文轉自 OneAPM 官方博客

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,001評論 6 537
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,786評論 3 423
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,986評論 0 381
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,204評論 1 315
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,964評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,354評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,410評論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,554評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,106評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,918評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,093評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,648評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,342評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,755評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,009評論 1 289
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,839評論 3 395
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,107評論 2 375

推薦閱讀更多精彩內容