JavaRush /Java Blog /Random-TW /如何寫乾淨的程式碼

如何寫乾淨的程式碼

在 Random-TW 群組發布
讓你的程式碼乾淨漂亮是按時完成任務的好方法。羅伯特·馬丁 (Robert Martin) 的一句話一語中的:“程式碼品質的唯一真正衡量標準是 What-The-F**ks/Minute 單位” 「原文)。 如何寫乾淨的程式碼 - 1讓我解釋一下這意味著什麼。每次我檢查程式碼時,我的大腦都會經歷以下三種情緒之一:
  • 「什麼鬼?!有沒有搞錯?!” (厭惡地)-不是這樣......一切都很糟糕......
  • 「什麼鬼?!有沒有搞錯?!” (欽佩) - 嗯,一個聰明人做到了!
  • 「什麼鬼?!有沒有搞錯?!” (憤怒地)-某種混亂,我們到底在說什麼?!
那麼什麼是最重要的呢?當我們看到一些程式碼時,我們到底要評估什麼? 就是這樣:它的純潔和美麗。能夠編寫乾淨漂亮的程式碼是一個高度專業的開發人員的標誌。 這項技能的訓練是基於兩個組成部分——知識和工作。知識教你模式、原則、實踐、啟發法。您需要他們的專業成長。只是你必須像海綿一樣透過不斷的練習和努力來吸收這些知識。簡而言之,要寫乾淨的程式碼並不容易。這是一項艱苦、艱苦的工作,你必須付出努力。透過反覆試驗,您將透過一遍又一遍地重複相同的步驟來改進,直到找到您想要的解決方案。根本沒有更簡單的方法。以下是一些提示,可幫助您學習如何編寫乾淨的程式碼。

名字裡有什麼

肯德里克·拉馬爾(美國嘻哈藝術家——編者註)曾經準確地指出:“如果我要講述真實的故事,我必須從我的名字開始。” 軟體開發領域的名字隨處可見。我們命名函數、類別、參數、套件、程式——一切。我們命名原始檔案和參考書以及與之相關的所有內容。我們無休止地命名事物,這成為創建乾淨程式碼的關鍵部分。你給某物取的名字應該反映其意圖。找到一個好名字並不容易,需要時間,但是當你必須處理程式碼並且情況變得複雜時,它也可以節省大量時間。因此,請小心此過程,如果您發現更合適的名稱,請不要害怕稍後更改名稱。每個處理你的程式碼的人都會非常感謝你。

請記住,任何變數、類別、函數的名稱都必須回答三個主要問題:它(變數、函數等)為何存在、它的作用以及它的用途。

這不僅需要良好的描述能力,還需要普遍的學識和廣闊的視野。沒有人比你自己更能教你這一點。

乾淨的程式碼

「一個功能」—一件事

路易斯·亨利·沙利文(美國理性主義和現代主義建築師)曾說過一句名言:“功能決定形式。 ” 他這樣說是關於房屋的建築,但這並沒有改變本質。每個系統都是基於程式設計師創建的某種特定於領域的語言來準確描述它的。函數充當語言的動詞,類別是名詞。大多數情況下,函數在程式語言的組織中至關重要,正確編寫函數是創建良好程式碼的本質。寫出質量函數只有兩個黃金法則:
  1. 它們應該很小
  2. 他們必須做一件事、一項任務,而且要把它做好
也就是說,您的函數應該很小並且不應該包含巢狀結構。因此,函數縮排等級不應超過一到兩級。這種方法使程式碼更容易閱讀、理解和理解。此外,我們必須確保函數內的表達式處於同一抽象層級。在函數中混合抽象層級總是會造成很多混亂,最終導致程式碼難以管理。最好的程式設計師將函數視為要講的故事,而不僅僅是要編寫的程式碼。他們使用所選程式語言的工具來創建豐富、富有表現力且簡潔的程式碼區塊,這些程式碼區塊本質上可以充當出色的說故事者。

“註解並不能彌補糟糕的程式碼”

美國網球運動員、五屆溫網冠軍維納斯威廉斯說得一針見血:「每個人都留下了自己的評論。謠言就是這樣出現的。 ” 評論就像一把雙面刃,一個恰到好處的評論是非常有用的東西。另一方面,沒有什麼比無聊、無用的評論更能讓空間變得混亂的了。但最具破壞性的評論是那些傳播錯誤訊息和謊言的評論。簡而言之,評論是一種必要之惡。並非總是如此,但在大多數情況下。為什麼?很簡單,註解越舊,維護起來就越困難,而且正如您所知,大多數程式設計師並不總是隨著程式碼的更改而更改註解。程式碼會移動和發展。部分程式碼來回移動,但沒有註解。這就成為一個問題!

請記住:乾淨、清晰且帶有少量註釋的程式碼比複雜、混亂的程式碼好得多。不要浪費精力去解釋你在評論中造成的混亂。最好花時間清理那些爛攤子。

乾淨的程式碼

“程式碼格式化始終是首要任務”

這句話的作者不是別人,正是 Robert C. Martin(羅伯特·塞西爾·馬丁),他又名 Bob 大叔、開發人員、許多軟體開發書籍的作者、顧問、敏捷宣言的合著者等等。他補充說:「格式化程式碼是一種溝通。對於任何專業開發人員來說,溝通都是重中之重。” 上述說法不應被低估,因為它道出了優秀開發人員最重要的特徵之一。格式化程式碼可以讓你深入了解你的想法。我們希望以我們的整潔、對細節的關注、清晰組織和表達我們思想的能力給人留下深刻的印象。但是,如果人們在查看程式碼時看到某種混亂,讓人想起油醋汁,既沒有開始也沒有結束,這就會抵消你的努力並降低開發人員的聲譽。甚至不要懷疑!如果您認為這個行業的主要事情是“程式碼可以正常工作”,那麼您就與事實相去甚遠了。您今天建立的功能很可能會在下一個版本中發生更改,但程式碼的可讀性不會改變。程式碼的風格及其良好的可讀性使得程式碼更容易長期維護,即使在原來的程式碼已經被改得面目全非之後。
永遠不要忘記,將來最有可能被記住的不是你的程式碼本身,而是你的風格和一致性。因此,請確保程式碼格式良好並遵循所有團隊成員都能理解的簡單規則。

首先建立一個「try-catch-finally」區塊

喬治·康吉萊姆(科學史家、哲學家)正確地指出:“犯錯對一個人來說是自然的,但堅持錯誤就是來自魔鬼。 ” 排除故障是所有程式設計師都會做的事情。輸入中可能會出現無效數據,且裝置可能會發生故障。作為開發人員,我們需要確保程式碼執行其應該執行的操作。問題不僅僅是錯誤處理,而是「乾淨且易於閱讀」的錯誤處理。許多程式都適應錯誤處理。如果這樣做,一切都會陷入混亂,以至於主程式碼的目的和邏輯都被破壞了。這是錯誤的,不應該是這樣的。程式碼應該是乾淨、可靠,錯誤處理應該無縫、自然地融入程式碼中。這是一個高級程式設計師的標誌。實現這一目標的一種方法是透過適當的嵌套和覆蓋 try-catch 區塊中的所有錯誤。這些區塊定義了程式碼的範圍。當您在 try-catch-finally 區塊的 try 部分執行程式碼時,您是在聲明執行可以隨時中止,然後在 catch 中復原。因此,我們建議您在編寫程式碼時從 try-catch-finally 開始。這將有助於確定用戶對程式碼的期望,無論程式碼在嘗試期間出現什麼問題。
永遠記住,您拋出的每個異常都必須包含足夠的上下文來確定錯誤的位置和來源。即使程式設計師已經忙於完全不同的任務,創造性和資訊豐富的錯誤訊息在程式碼編寫後很長時間也會被記住。
乾淨的程式碼

讓我們總結一下

一個不尋常的短語將幫助我們總結以上所有內容。這就是代碼意識或“通用代碼意識”,相當於程式設計師的常識。用羅伯特馬丁的話來說:「編寫乾淨的程式碼需要係統地使用許多小技術,這些技術的應用是由於一絲不苟且有些痛苦的「清潔」意識而應用的。這些小技巧統稱為代碼感知。 ” 我們中的一些人從一開始就有這種“良好的代碼意識”,而另一些人則必須透過堅持不懈的練習來發展它。這種本能不僅有助於識別壞程式碼和好程式碼之間的區別,而且有助於形成旨在將壞程式碼轉化為好程式碼的策略。糟糕的程式碼會毀掉一切。打個比方,如果你在最美味的蛋糕上撒上狗屎,那麼……呃……幾乎沒有人會喜歡它。程式碼意識幫助程式設計師使用正確的工具來實現創建乾淨程式碼的目標。理解什麼是程式碼感知的程式設計師就是一位藝術家,他可以在空白螢幕上創作出令人銘記多年的藝術品。正如麻省理工學院電腦科學教授、知識共享和自由軟體基金會創始主任哈羅德·“哈爾”·阿貝爾森 (Harold “Hal” Abelson) 所總結的那樣:“首先需要編寫程序,以便人們可以閱讀它們,然後才能將它們被處決。“汽車”。您可以閱讀有關該主題的內容:“敏捷軟體工藝手冊”- Robert Martin。「敏捷估算手冊」- Mike Cohn 作者簡介:Ravi Shankar Rajan 是來自印度孟買的全球 IT 專案經理。著名部落客、俳句詩人、狂熱的考古學和歷史愛好者。 您可以透過TwitterMediumLinkedIn與他聯繫
留言
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION