Clean Code_Note1_Eliminate poor names in code

 

Clean Code三大特性

Easy to read

Easy to maintain

Easy to extend

經常阻斷我們執行Clean Code的7大迷思(以微軟程式方面)

1.不知道從哪開始?

事實上可以從系統個部分隨時都能開始推動，但更動和撰寫必須局部小型範圍在實踐。

可以嘗試開始去判斷說哪邊變數、函數命名有點不妥，或是去刪除較冗長的methods。

2.既有的專案程式尚未導入unit test

其實大部分legacy code可能功能都寫比較複雜或是有點混亂。

所以對這類程式做unit test反而沒有效果，做unit test之前還建議先進行clean code的重構。

3.沒有Resharpper，有點太貴沒預算。

Resharpper是很厲害一套工具但非必要，用vs內建的即可不需花額外的錢。

4.不曉得到底有多少code要進行clean up?

不要想一次把所有程式 clean up ，只先進行自己份內即可，clean up code是需要長期推動的。

5.沒有時間去clean code...

clean code事實上應該不算是額外要被劃分出來的工作任務，反而是在撰寫需求時就也要同步進行的。

6.不曉得何時寫clean code

通常在bug修復或者寫新需求的時候。

7.對Design Pattern可能還沒全部掌握甚至沒有接觸過是否就無法導入clean code

事實上design pattern實踐是在clean code後才進行，所以也可以先不需要太鑽研design pattern就能先進行clean code。

clean up code心法

1.Eliminate poor names in code

Case1.

Before

Ctrl+R, Ctrl+R 重新改名

After

Case2.

Before

After

Case3. 容易混淆的method命名

Case4. 取有意義的名稱

以下這三個method名稱感覺做的事情都類似

若今天要做從DB fetch document的任務要call哪一支，這時可能還是要花時間每一支method都去看過或debug一次才知道。

Case5. 不要亂縮寫盡量取能夠知道如何發音的名稱，除非團隊內已經有一套縮寫命名的共識。

Case6. 盡量不要用hungarin notation，除非團隊規定。

Case7. 不要用一些自創的用語或笑話來命名，盡量用有共識跟共同語言來做命名描述

Dispose就 Dispose不要自創 SendToGraveyard

Case8. 盡量不要出現Magic Number

盡量額外宣告且命名為有意義的常數