• 「Clean Code 是可被原作者以外的開發者閱讀與增強的。它應當包含單元測試與驗收測試
• 「減少重複、具有高度的表達力、並及早建立簡單抽象概念，這些對我而言，就是撰寫 Clean Code 的方法」
• 「當每個你看到的程式，執行結果都與你想得差不多，你會察覺到你正工作在 Clean Code 之上」

以上這是在書上的定義

那為了實現Clean Code 我們到底該要做的是什麼呢？
這邊我會分成6個部分

1. 命名
2. 註解
3. 編排
4. 函式
5. 錯誤處理
6. 測試

有意義的命名

在開始之前先補充一下常見的命名法

• 小駝峰 (lowerCamelCase)
  • 第一個單字以小寫字母開始；第二個單字的首字母大寫，例如：firstName、lastName。
• 大駝峰 (UpperCamelCase)
  • 每一個單字的首字母都採用大寫字母，例如：FirstName、LastName、CamelCase
• 蛇型命名 (snake_case)
  • 利用底線來連接單字，然後全部都是小寫 ，例如：first_name、last_name、camel_case

什麼是有意義的命名

• 看名稱就知道在幹嘛
• 不要有誤導情況的發生
• 是有辦法唸出來的
• 可以被搜尋

看名稱就知道在幹嘛

假如今天我們要來找目標顏色是否在顏色陣列中

//Bad

const tc = "red"; 
const fc = false; 
const ls = ["yellow","red","green"];

//Better
const targetColor = "red";
const findColor = false;
const colors = ["yellow","red","green"];

不要有誤導情況的發生

以顏色陣列為例的話

//Bad
const colorList = ["yellow","red","green"];

//Better

const colors = ["yellow","red","green"];
const colorsArray = ["yellow","red","green"];
const colorGroup = ["yellow","red","green"];

因為List這個單字有可能對應到 Linked-List，你用colors、colorArray、colorGroup都比你用colorList好一點

是有辦法唸出來的

取名稱還是讓他可以被唸出來比較好一點拉，除非是大家都知道的縮寫

//Bad

const mu_biao = "red"; //別用拼音！！！
const tatc = "red" //縮寫還是大家看的懂比較好拉
const 🫵 = "red" //你嗑了什麼！？

function targetColorFind(){ //按照文法的話念起來比較不順，較不容易記憶
	//...
}

//Better

const targetColor = "red";

function findTargetColor(){
//...
}

可以被搜尋

今天如果是要去修改檢查 email 的 function 好了，通常我們找程式為搜尋的關鍵字不外乎是 ：
email 、check、validate 之類的 ，那如果你的function剛好長得像

const userFirstInputComparison = () => {
	//...
}

恩….那我可能找不到你的function

物件跟函式相關

方法的命名方式也盡量統一，物件內的話就避免重複物件的名稱

//如果這些是專門user相關資料的function

const getUserName = () => {
//...
}

const getUserEmail = () => {
//...
}

const fetchUserGender = () => {
//...
}

const fetchUserHeight = () => {
//...
}

假如你看到這個程式碼，應該會有個疑問，get 跟 fetch 不是差不多的意思嗎？ 怎麼會同時出現，雖然他們的命名沒什麼問題，但可以的話專案請統一動作的名稱

• 取出器 (accessors): 使用 get 當字首
• 修改器 (mutators): 使用 set 當字首
• 判定器 (predicates) 使用 is 當字首

物件

直接看範例應該就很清楚了，不用重複物件本身的名字了

// Bad 

const book = {
  bookTitle: "Clean Code",
  bookId: 12345,
  bookAuthor: "author",
  bookISBN: "123-456-789",
};

// Better 

const book = {
  title: "Clean Code",
  id: 12345,
  author: "author",
  isbn: "123-456-789",
};

檔案結構命名

這是我們用 create-react-app 建立的react app

my-app/
  README.md
  node_modules/
  package.json
  public/
    index.html
    favicon.ico
  src/
    App.css
    App.js
    App.test.js
    index.css
    index.js
    logo.svg

我們可以從範例來看，他在每個檔案的命名都可以讓你知道他是做什麼的，那往下個例子，如果今天專案複雜一點的話呢 （這邊檔案結構大家習慣會不同，還請不要介意）

my-app/
  README.md
  node_modules/
  package.json
  public/
    index.html
    favicon.ico
	assets/
		2023_06_04.png
		IMG_8787.png
	components/
		first-element/
			index.js
		second-element/
			index.js
	pages/
		first-page/
			index.js
		second-page/
			index.js
  src/
    App.css
    App.js
    App.test.js
    index.css
    index.js
    logo.svg

當然上述例子應該很難在專案中看到，但如果你剛拿到這個專案的話，一定不知道components裡面的那些東西是幹嘛用的，那如果我們將 File structure 簡單的改成下方這樣呢？

my-app/
  README.md
  node_modules/
  package.json
  public/
    index.html
    favicon.ico
	assets/
		homepage.png
		introduction.png
	components/
		navbar/
			index.js
		article/
			index.js
	pages/
		homepage/
			index.js
		introduction/
			index.js
  src/
    App.css
    App.js
    App.test.js
    index.css
    index.js
    logo.svg

是不是就清晰很多，至少可以知道那個檔案裡面的東西是什麼，所以在命名資料夾或是檔案名稱的時候，盡量不要使用沒有意義的命名。
其實命名上面還是有很多眉眉角角的，這篇介紹只是冰山中的一角，如果大家有興趣更深入的話，歡迎去閱讀
無瑕的程式碼－敏捷軟體開發技巧守則 (Clean Code: A Handbook of Agile Software Craftsmanship)