![Kinds of Names to Avoid
1. 避免唸起來很像的名稱
• wrap and rap
2. 避免相同名稱，意思不同或不同名稱，意思相似
• offer_id / offer_no/ offer_num
3. 避免使用數字，使用陣列解決
• file_1, file_... / file[i]
4. 避免易拼錯的字
5. 避免使用程式語言關鍵字
6. 避免使用完全無關的名稱(或者全世界只有你一個人知道相關性的
名稱)](https://image.slidesharecdn.com/codecomplete2ch11thepowerofvariablenames-170904153649/85/The-Power-of-Variable-Names-26-320.jpg)
The Power of Variable Names
- 1. The Power ofVariable Names Roy Chen@20170904
- 2. The Power ofVariable Names • 今天要討論“變數名稱的力量”，這力量有可能是好的力 量，也可能是不好的力量。 • 接著會從幾個主題去讓我們的變數名稱都能發會出好的力 量。
- 3. Agenda 1. Considerations inChoosing Good Names 2. Naming Specific Types of Data 3. The Power of Naming Conventions 4. Informal Naming Conventions 5. Standardized Prefixes 6. Creating Short Names That Are Readable 7. Kinds of Names to Avoid
- 4. 1. Considerations inChoosing Good Names 取個好名字要考慮的點有哪些
- 5. The Most ImportantNaming Consideration • 變數名稱最重要的是「可以完整而正確的描述」實際的意義 • 一個好的名字，在於反映"What is the problem"，而不是"How the solutions work” • 一個變數要放員工資料，該取inputRec 或 employeeData ? • 就運算或資料流程的觀點來看，是inputRec沒錯(How)，但我們會不知道這實際是什 麼？(What)。
- 6. 變數名稱的長短？ • 根據研究，平均長度10~16 個字元可以讓除錯的心力，降到最低 •Are short variable names always bad? • No, not always. • 較少使用、全域變數可以用長名稱 • 迴圈變數、區域變數可以用短名稱 • 對於有支援namespace的語言: 使用namespace管理
- 7. Other Considerations • 計數專用修飾詞需統一前綴或後置 •避免出現totalPrice和priceTotal的混淆 • 使用常見的成對變數名稱 • up/down • first/last • old/new
- 8. 2. Naming SpecificTypes of Data 為特定資料型態命名
- 9. 為特定型態的資料命名 • 這裡的型態(type)並不是int/float這種，而是指變數在context中代 表的用途。 • 分類如下 1.命名迴圈的索引變數 2. 命名狀態變數 3. 命名臨時變數 4. 命名布林變數 5. 命名列舉型別 6. 命名常數
- 10. 6類型態的命名要點 1. 命名迴圈的索引變數 • 如果是多層不要用ijk，一層還好 •Callback function也一樣，巢狀的話就不要都用cb/callback這種名字 2. 命名狀態變數 • 變數裡不要有flag這單字，因為當用了flag就代表有隱喻了 • 應該要用明示的方式來取名，statusFlag => dataReady • 至少要給別人這個flag的型態提示，boolean or Number? 3. 命名臨時變數 • tmp/ x / y / z • 「臨時變數」= 程式設計師尚未完全了解問題 • 除非像是swap裡的tmp…就ok
- 11. 6類型態的命名要點 4. 命名布林變數 • 讓變數名稱有真假的隱喻 •status = true; / statusOk = true; • IsXX的命名方式(isDone?isError?isFound?isProcessingComplete?) • Use positive boolean variable names, 像if !notFound ... 5. 命名列舉型別 • 使用前綴詞確保變數屬於同一組或同型態 • Color_Red / Color_Green / Color_Blue • Planet _Earth / Planet _Mars / Planet _Venus 6. 命名常數 • 命名請用常數代表的含義，而非常數代表的值 • Width-800px / body-width
- 12. 3. The Powerof Naming Conventions 命名慣例的力量
- 13. Some programmers resiststandards and conventions • 此章的引言提到：有些開發者排斥遵從開發標準或慣例，理由是 死板且沒效率，這阻礙了他們的創造性與品質。 • 但其實好的Naming Conventions帶給團隊的好處正是品質與效 率。 • 所以此章節教我們如何用Why/When/How來思考，並設計出好的 Naming Conventions 。
- 14. • (Why) 為什麼要有命名原則 •更專注在程式的邏輯上 • 彌補程式語言的弱點 (ex. 弱型別, 或免宣告) • 提高閱讀程式碼的速度 • (When) 何時該使用命名原則 • 多位程式設計師合作一個專案 • 程式會交給別人維護 • 程式規模超大，子系統很多 • (How) 正式的程度，慣例要訂到多細多嚴謹 • 寫程式的人數 • 程式大小 • 程式預估壽命
- 15. Not only inNaming Conventions • 其實這章節提到的why/when/how也可套用到coding convention， 例如縮排甚至是IDE config等等。
- 16. 4. Informal NamingConventions 通俗的命名慣例
- 17. 通用或語言限定的命名慣例 • 無關語言的一個公定原則 • 用字首大小寫來區分型態與變數，ex. Widget widget; • 特定語言的公定原則 • Ex. c/c++: p is a pointer
- 18. Mixed-Language Programming Considerations • 當你的專案或環境需要有多語言共存時，就不一定要堅守語言的 公定原則。 •這裡不單單指命名慣例，as well as formatting conventions, documentation conventions, and other conventions • Ex. html + smarty(a kind of php template engine) • 根據“Google HTML/CSS Style Guide”,html縮排是用2 spaces • 但如果混著template engine，兩個空格可能不好閱讀(因為夾雜著php的 程式邏輯)
- 19.
- 20. Prefixes Definition • 類似匈牙利命名法，使用datatype(int/float/point...)來當前綴詞， ex. bValid (boolean type) • 但這本書在這裡指的是資料種類而不是資料型別 • win(window) / doc(document) • winMain / docActive
- 21. 採用前綴字命名法好嗎？ • 正方表示： • 名稱更加精簡 •方便檢查型別與種類 • 反方表示： • 如果你不知道一個變數是做什麼的，知道了它的類型也沒什麼幫助。 • 標準化前置詞的可讀性有時候不如一個更具描述性的名稱。
- 22. 6. Creating ShortNames That Are Readable 建立易懂的短名稱
- 23. 用文法或發音來縮寫 • 一般的縮寫原則 • 使用字典中會用的標準縮寫,ex. Additional => addl • 移除冠詞, ex. the/a/an • 同音縮寫 • skating = sk8ing ( at = 8 ) • highlight = hilite ( hight = hi, light = lite ) • before = b4 • execute = xqt • offer2order
- 24. 文化背景差異 • 我自己覺得用常見的發音去縮寫是可以的，但因該還是要考慮到 文化背景的問題。 • 例如團隊中大部分都不是英語母語的開發者來說，就不應該用罕 見或艱深的英語發音縮寫。 •至於能不能用非英語的其他語言來縮寫變數？這當然最好是不要， 即便專案初期的成員不是跨國的，還是需要避免才對。
- 25. 7. Kinds ofNames to Avoid 要避免使用的名稱
- 26. Kinds of Namesto Avoid 1. 避免唸起來很像的名稱 • wrap and rap 2. 避免相同名稱，意思不同或不同名稱，意思相似 • offer_id / offer_no/ offer_num 3. 避免使用數字，使用陣列解決 • file_1, file_... / file[i] 4. 避免易拼錯的字 5. 避免使用程式語言關鍵字 6. 避免使用完全無關的名稱(或者全世界只有你一個人知道相關性的 名稱)
- 27. 打錯字有兩種 7. 避免拼字錯誤，打錯字有兩種… • 宣告或建立時就錯了 •important / important?? • 要將錯就錯還是徹底地改一輪呢？ • 這類錯誤可能比較難用plugin檢查？此時code review很重要 • 使用變數時打錯字 • Editor Plugin • use strict mode(IDE / compiler / language support)，例如一定要宣告變數才能使 用 • Ex. JS不用宣告就可以用，所以拼字錯誤時也不會發現
- 28.