說實話，每個開發人員（是的，即使是擁有多年經驗的開發人員）在某個時候都發布過混亂的程式碼。
編寫乾淨的程式碼不是什麼精英技能。這是一個你可以養成的習慣。還有重構？這正是讓您的程式碼真正有意義的機會 — — 無論是對您還是對以後維護它的人來說都是如此。
讓我們分解一下。沒有絨毛。沒有抽象的理論。僅提供實用的、真實的技巧來幫助您編寫乾淨、可維護的程式碼。
1. 說出你想說的話
您的變數和函數需要講述一個故事。
不是x 、不是temp 、不是data 。那些只是為了造成混淆的佔位符。
✅好： getUserProfile()
❌不好： getData()
✅好： maxLoginAttempts
❌不好： m
當你為事物命名時，你的程式碼就可以自我解釋——無需任何偵探工作。
2. 少即是多：函數大小的力量
如果您像瀏覽一篇文章一樣瀏覽某個功能，那就表示出現了問題。
長函數難以閱讀、難以除錯、難以維護。相反，將它們分解為更小的、單一用途的功能。
這樣想：每個函數都應該回答一個問題。如果答案是五，就把它分開。
例子：
// Instead of this
function processUserData(user) {
validateUser(user);
saveToDatabase(user);
sendEmail(user.email);
}
// Do this
function validateAndSaveUser(user) {
validateUser(user);
saveToDatabase(user);
}
function notifyUser(email) {
sendEmail(email);
}這使得您的程式碼更易於閱讀和重複使用。未來——你會感謝你自己。
3. 一致性是關鍵
您是否曾經在這樣的專案中工作過：其中userList在一個地方被稱為users而在另一個地方activeUsersArray ？混亂。
保持命名約定、縮排和格式一致。當您的程式碼遵循可預測的模式時，它會更易於閱讀，也更易於除錯。
✅好： userList, orderList, productList
❌不好： users, ordersList, listOfProducts
選擇一種慣例並堅持它。沒什麼意外。
4. 有目的地發表評論，而不是出於習慣
評論應該解釋為什麼，而不是什麼。如果您的程式碼需要註解來解釋其作用，請重寫程式碼。
例子：
// ❌ Bad Comment
// Increase count by 1
count = count + 1;
// ✅ Good Comment
// Edge case: Prevents counter from going negative
if (count > 0) {
count--;
}寫出有價值的評論，而不是那些顯而易見的評論。
5. 魔法數字和硬編碼值－擺脫它們
曾經看過隨機數的函數嗎？是的，這是一場維護的惡夢。
相反，使用常數來使這些值有意義。
例子：
// ❌ Bad
if (user.loginAttempts > 3) {
lockAccount(user);
}
// ✅ Good
const MAX_LOGIN_ATTEMPTS = 3;
if (user.loginAttempts > MAX_LOGIN_ATTEMPTS) {
lockAccount(user);
}好多了。
6. DRY：不要重複自己
重複的程式碼只等待被打破。如果您發現自己在複製貼上，請停止。建立可重複使用的函數或模組。
例子：
// ❌ Bad: Duplicated logic
sendEmail(user.email, "Welcome!");
sendEmail(admin.email, "New user registered!");
// ✅ Good: Reusable function
function sendNotification(email, message) {
sendEmail(email, message);
}
sendNotification(user.email, "Welcome!");
sendNotification(admin.email, "New user registered!");這樣，當需要更改時，您只需在一個地方進行更新。
7. 保證程式碼可靠
如果您還沒有聽說過SOLID 原則，現在是開始了解的好時機。這五個簡單的規則可以讓您的程式碼更清晰、更易於維護。
如果沒有別的，就從這個開始：單一責任原則。
➡每個函數/類別都應該只做一件事，並且做好它。
如果您的類別同時處理使用者身份驗證和資料庫存儲，那麼是時候進行重構了。
8. 徹底重構
編寫乾淨的程式碼不是一次性的事情。這是一種習慣。
每次檢查程式碼時，都要尋找改進方法：
-
為了更清楚起見，您可以重新命名變數嗎？
-
你能分解一個巨大的函數嗎？
-
你能刪除不必要的留言嗎？
不要等到進行重大重寫後再進行重構。
例子：
// ❌ First draft
function fetchUserData(userId) {
return fetch(`https://api.example.com/user/${userId}`)
.then(response => response.json())
.catch(error => console.error(error));
}
// ✅ Refactored
async function fetchUserData(userId) {
try {
const response = await fetch(`https://api.example.com/user/${userId}`);
return await response.json();
} catch (error) {
console.error(error);
}
}重構並不意味著您的第一次嘗試很糟糕 - 它意味著您正在使其變得更好。
如果可以的話：
✅ 明確命名事物
✅ 保持函數小巧
✅ 保持一致
✅ 避免使用硬編碼值
✅ 經常重構
...你已經遙遙領先了。
原文出處：https://dev.to/balrajola/how-to-write-clean-code-refactoring-and-best-practices-315h
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式