想像一個房間如此混亂，你找不到鑰匙。衣服到處都是，書籍堆積如山，一片混亂。
現在想像一下在混亂的程式碼中工作。
這是同樣的災難，除了現在是你的大腦失去了理智。
另一方面，乾淨的程式碼就像走進一個一塵不染的房間。一切都在它應該在的地方。沒有壓力。沒有混亂。只是清晰度。
事實是這樣的：如果您想在軟體開發中取得成功，編寫乾淨的程式碼不是可選的。
你可以寫混亂的程式碼，成為努力修復每個錯誤的人，或者你可以掌握乾淨的程式碼並主宰你接觸的每個項目。
讓我畫一幅畫給你。
下面的圖表顯示了兩種類型編碼員的旅程：
現在，您決定要跟隨哪條線路。
為了示範此圖表，在初始開發階段，糟糕的程式碼比乾淨的程式碼更改成本略高。
然而，當我們進入維護和重構階段時，差距顯著擴大，糟糕的代碼成本幾乎是乾淨代碼的兩倍。
到遺留階段，不良代碼達到100% 成本，現在更新成本極其昂貴，而乾淨的代碼仍然更易於管理，為 45%。
毫無疑問，糟糕的程式碼是軟體開發中代價高昂的問題。
命名變數或函數 b 或 x 是犯罪行為。就這樣稱呼他們吧。
// Weak and vague let b = 5; // Strong and clear let numberOfUsers = 5;
名字寫不清楚的人不想承認自己的錯誤。 不要成為那個人。
函數應該要做一件事－－而且做得很完美。這稱為單一職責原則 (SRP)。
好的程式碼就像錘子。它擊中了一根釘子，不是十個。
// Clean: One job, one focus
function calculateTotal(a, b) {
return a + b;
}
function logTotal(user, total) {
console.log(`User: ${user}, Total: ${total}`);
}
// Dirty: Trying to do EVERYTHING
function calculateAndLogTotal(a, b, user) {
let total = a + b;
console.log(`User: ${user}, Total: ${total}`);
}
當你混合任務時，你將混亂與災難混合在一起。
你不解釋每次有人走進房間時門的作用。您的程式碼應該以同樣的方式運作。
// Clean: Self-explanatory let userAge = 25; // Messy: Needs an explanation let a; // This means "age of the user"
評論還不錯，但是如果你的程式碼不能獨立存在，那你就已經失敗了。
如果有人讀你的程式碼時感覺他們正在解謎，你已經成為了一個麻煩製造者。
// Clean: Reads like a story
if (isLoggedIn) {
console.log("Welcome!");
} else {
console.log("Please log in.");
}
// Messy: Feels like chaos
if(isLoggedIn){console.log("Welcome!");}else{console.log("Please log in.");}
可讀程式碼不只適合其他人，六個月後也適合你。
如果你懶得寫測試，當你的程式碼崩潰時不要抱怨。
class Calculator {
add(a, b) { return a + b; }
subtract(a, b) { return a - b; }
}
// Test it (Unit Test)
const calculator = new Calculator();
console.assert(calculator.add(2, 3) === 5, "Addition failed");
console.assert(calculator.subtract(5, 3) === 2, "Subtraction failed");
測試是您的保險。忽略它們，你就是在拿時間賭博。
依賴就像交易。找到正確的，你就贏了。如果選擇不當，你就會陷入讓自己後悔的事情。
// Dependency: Sending emails with Nodemailer
const nodemailer = require('nodemailer');
function sendEmail(to, subject, message) {
const transporter = nodemailer.createTransport({ /* config */ });
return transporter.sendMail({ from: "you@example.com", to, subject, text: message });
}
避免硬編碼依賴。使用抽象或設定檔進行安全維護。
這只是一個例子。作為開發人員，您可能會使用數百個程式庫或依賴項。
我並不是說你不應該依賴它們，現在很難避免它們。但在將它們安裝到編碼專案中之前，您應該非常小心。
您應該檢查組織軟體系統的安全性、效能、品質或功能。因為它們有時包含可能毀掉您整個專案的風險。
始終控制你的工具，不要讓它們控制你。
組織良好的項目是舊貨拍賣和高端精品店之間的區別。
myProject ├── src │ ├── components │ ├── services │ ├── utils └── tests
如果你的程式碼庫看起來像一個垃圾抽屜，那麼你已經失去了未來的自己的尊重。
電子郵件應用程式的可靠專案結構：
假設您正在建立一個向使用者發送電子郵件的應用程式。你的老闆般堅不可摧的 SOLID 專案架構應該如下圖所示：
不要像擁有 10 種性格的人一樣編碼。與您的格式保持一致。
使用 Prettier 或 ESLint 等工具來強制執行一致的風格。如果每個文件看起來都不同，那麼您就會造成無人願意修復的混亂。
我想說，格式的一致性是乾淨程式碼的基本原則，因為它保證了可讀性。
看看...
在整個程式碼庫中一致使用 2 或 4 個空格 來縮排。 避免使用製表符以在不同編輯器之間保持一致性。
將行最多 100-120 個字以防止水平捲動並提高可讀性。
將相關邏輯組合在一起和單獨的程式碼區塊，並使用空行來突出顯示其目的。
最後，避免過度對齊程式碼；相反，讓縮排自然地引導邏輯流程。
硬編碼是偽裝成努力的懶惰。看看：
// Weak and vague let b = 5; // Strong and clear let numberOfUsers = 5;
所以，硬編碼是讓你墜入懸崖的捷徑。
如果你的函數超過 20 行，它可能是試圖做太多事情。 分解它。
// Clean: One job, one focus
function calculateTotal(a, b) {
return a + b;
}
function logTotal(user, total) {
console.log(`User: ${user}, Total: ${total}`);
}
// Dirty: Trying to do EVERYTHING
function calculateAndLogTotal(a, b, user) {
let total = a + b;
console.log(`User: ${user}, Total: ${total}`);
}
短函數是銳利函數。 他們每次都達到目標了。
任何人都可以寫混亂的程式碼。即使人工智慧也能製造垃圾。
但是寫乾淨的程式碼嗎？這就是區分業餘程式設計師和專業程式設計師的技能。
你想主宰軟體開發嗎？ 寫乾淨的程式碼。就這麼簡單。
那如何寫乾淨的程式碼呢？
讓我告訴你一件事- 你剛剛在本文中讀到的內容只不過是我的書中海洋中的一滴水知識，從零到一的乾淨程式碼。
這10條規則？它們只是表面。
這本書深入探討了每一個原則、每一個規則和每一個技術，並以清晰詳細的方式進行了解釋，讓你永遠不會忘記它們。
我在其中包含了數千張數位插圖和真實場景，它們不僅可以教你，還可以帶你進入乾淨編碼的世界，這是你所無法想像的。曾經見過。
事實是：混亂的程式設計師無法生存。他們淹沒在自己的混亂之中。乾淨的程式設計師占主導地位。他們編寫的軟體能夠經受時間的考驗，而且他們從不為無法修復的錯誤或無法添加的功能而苦苦掙扎。
如果你認真地想展現你寫程式的方式，那麼這本書不是一個選擇－它是必備。
因為今天是聖誕節，所以我會讓這對你來說變得容易。使用促銷代碼 MERRYCHRISTMAS 即可獲得 50% 折扣。
但不要等太久－此優惠將於2024 年 12 月 31 日結束。
點擊下面的鏈接，獲取該書。
？ 立即取得乾淨的程式碼從零到一
選擇權在你。您可以繼續編寫混亂的程式碼，浪費時間和精力，或者您可以控制，學習主導您的項目，並像老闆一樣建立軟體。
？ 追蹤我了解更多： @shahancd
？ 我的每週電子報： Horscoder
閱讀更多：在 React 中寫乾淨、可重複使用的元件
以上是如何編寫乾淨的程式碼 - 為開發人員提供的提示和範例的詳細內容。更多資訊請關注PHP中文網其他相關文章！
