我的程式碼會說話 第1章 劣質程式碼帶來的劣質體驗

     《我的程式碼會說話》是很好的的輔助教材，《Clean Code》 與 《Code Complete》 中文版文字太多！部分片段沒有相關程式經驗根本無法看懂。《我的程式碼會說話》寫得比較簡潔易懂。第一章作者舉出常見程式沒寫好的情況。

1.1 程式碼的可讀性問題

 

讀者的行為能夠反映出程式碼存在的問題：

 

一直滾動滑鼠滾輪  方法過長

總是做全域搜尋  方法過長

反覆地查看方法實作  命名無法反映其真實意義

不停地查看呼叫方法的實作  呼叫層次太多

反覆查看全域常數的值  常數定義方式無法反映其實質

畫流程圖  巢狀太深

 

閱讀上的問題分為五大類

 

命名

註解

結構

架構

風格

 

1.1.1  命名類的問題

避免出現變數a、b、c，方法a()、b()、c() 。

1.缺乏統一性

介面、方法與變數的命名都應該遵守一定的規則。

2.沒有考慮呼叫時的情形

班級Grade類別，獲取學生數量該用下面哪種命名？

grade.getStudentsCount();  // get 有點多餘

grade.countStudents();  // 這是一個行為，給人需要時間的感覺

grade.students.size();  // 不容易理解，但書寫起來最簡單

grade.size();  // 有被誤解為班級的房間大小的可能

grade.studentsCount();  // 能夠反映學生數量的要求

3.語言命名

儘量用英文命名，不要用本地語言

4.命名用詞不當

避免用錯英文單字

5.超長的命名

6.命名含意模糊

7.命名和行為不一致

方法的命名和實際行為不一致，容易會出現程式碼錯誤。

8.否定式命名

if((hardKeyboardHidden==0)==false)  不容易理解

if(hardKeyboard.isConnected()) 比較容易理解

9.無意義的命名

例如temp不表示有特定的含意。

10.序號式命名

例如LAYER1、LAYER2、LAYER3 三個常數不能對讀者產生有價值的資訊。

11.工程名稱為類別名稱的首碼

類別之前有相同的工程名稱只會增加閱讀困難。

12.超短命名

a、b、c 命名沒有提供有用的資訊，迴圈用i、j、k 變數則是無妨。

13.匈牙利命名法

避免使用匈牙利命名法。

student.strScore 不如 student.score 順暢

1.1.2 註解類的問題

1.每步皆註解

 

程式碼才是主要資訊，註解是輔助資訊。

 

2.錯誤的註解

 

3.修改歷史記錄註解

 

有版本管理工具，不需要再寫歷史記錄註解。

 

4.長方法的分段註解

 

函數太長必須寫註解才能了解內容，解決之道是縮短函數長度。

 

5.複製名稱的註解

 

6.複製說明文件的註解

 

長篇的本地語言出現在程式碼之中，會讓程式碼不容易閱讀。

 

7.缺少註解

 

8.自動產生的JavaDoc註解

 

書中舉出的範例JavaDoc註解是多餘的資料。

 

1.1.3  風格類的問題

 

1.長方法

 

2.長參數列表

 

參數過多會讓程式碼複雜度變高，也帶來閱讀困難。

 

3.長判定語句

 

4.長分支

 

太多選項的switch/case 或 if/else

 

5.魔法數字

 

6.字串直接引用

 

字串散落在程式各處，多語系化工作變得不易。

 

7.冗餘的常數定義

 

(1)組合常數

 

為了記憶 Shift 和 Alt 按鍵的狀態而定義的常數。

 

這些常數可用mAlt 和 mShift 所取代。

 

(2)長清單遍佈常數

 

70個按鍵每個按鍵定義一個常數。改善方法按鍵透過物件定義，透過定義屬性對按鍵進行分類，透過屬性判斷按鍵是否為輸入字元。

 

8.意義不明的邏輯

 

9.變數意思不穩定

 

10.回傳值意思不穩定

 

11.無用的方法或變數

 

12.詭異程式碼

 

例如 b=(--c<<a>>3)*(a++)

 

1.1.4 結構類的問題

 

1.do-while禁用引起的重複

 

2.switch-case 引起長分支

 

每個鍵盤安排一個值會引發長分支，先將按鍵分類程式可以精簡很多。

 

3.  莫名奇妙的default

 

可用多型取代switch-case

 

4.被忽略的Exception

 

有抓Exception卻沒有處理。

 

5.全域變數做為回傳值

 

？？？？？？？？

 

6.不必要的Guard程式碼

 

確保物件不是null，可以不用寫檢查null的判斷。

 

7.巢狀過深

 

範例中二維陣列改為一為陣列，避免巢狀過深。

 

8.輸出型參數

 

9.冗餘的臨時變數

 

考慮用Map取代List

 

10.不合理的錯誤變化

 

Exception的區塊不應該有影響正常程式的程式碼。

 

1.1.5 架構類的問題

 

1.關係混亂

 

(1)循環引用

 

兩個類別互相引用對方的資料，作者舉例可用中間類別（？）解決循環引用的情況。

 

(2)錯誤的繼承

 

基底類別有太多衍生類別不需要的屬性或方法

 

(3)不當的從屬關係

 

Keyboard 與 Candidate 不是從屬關係（has a），可將兩者放在同一個類別。

 

(4)大雜燴類別

 

類別沒有進行MVC分離，承擔太多職責。

 

2.重複與類似

 

會導致一處變更處處變更，少一處忘記變更會引發錯誤。

 

3.層層深入的private方法

 

原有的程式碼太長一直採用方法提取，導致出現很多層private方法。

 

4.墨守成規

 

寫入資料與更新UI是兩件事情，不應該在一起。

 

1.2 程式碼的可測試性問題

 

1,難以建構測試設備

 

環境複雜，例如要初始化許多變數才能開始測試。

 

2.難以拆分做單元測試

 

單元之間耦合度太高會造成很難進行單元測試。

 

1.3 程式碼的可維護性問題

 

程式碼會一直變化，需求改變與出現Bug都會導致程式碼發生變化。

 

1.3.1 需求變更難以應對

 

寫程式的時候就要想到需求變更，考慮可擴充性。

 

1.黏滯（牽一髮而動全身）

 

2.脆弱（一旦修改就會破壞原有結構）

 

3.僵硬（程式碼間總是互相牽制，導致難以入手）

 

1.3.2 糾纏不清的Bug

 

1.難以重現的Bug

 

2.難以定位的Bug

 

3.難以修改的Bug