1
為什麼程式碼要易讀 ?
2
3
除了我之外
沒有人會看這 程式份
也許 會你 說
↓
4
5
三元運算子與一行化的愛恨情仇
return ( Z > B ) ? True : False ;
if ( Z > B ) {
   return True ;
} else {
   return False ;
}
6
return ( Z > B ) ? True : ( X > Y ) ? True : False ;
↓
return ( Z > B ) ? True :
( X > Y ) ? True : False ;
這已經是一種性功能障礙了
7
一行化的暗示
‧ 程式碼越少效率越好
‧ 一行化比較潮
‧ 看不 的人會叫我大大懂
8
Naming
9
10
int tmp = 0;
for (int x=0; x<24; x++){
for (int y=0; y<60; y++){
for (int z=0; z<60; z++){
tmp++;
}
}
}
return tmp;
11
int sumSeconds = 0;
for (int hour=0; hour<24; hour++){
for (int min=0; min<60; min++){
for (int sec=0; sec<60; sec++){
sumSeconds++;
}
}
}
return sumSeconds;
12
加入額外的輔助資訊
Public int createCache(int size);
Public int createCache(int sizeByMB);
Public int createCacheByMB(int size);
13
具體、具體再具體
Animal
↓
Cat
↓
Tiger
14
AnAppleADayKeepTheDoctorAway
anAppleADayKeepTheDoctorAway =
New AnAppleADayKeepTheDoctorAway(“Apple”);
BestFruit bestFruit = new BestFruit(“Apple”);
15
排版慣例 1
( 小 ) 駝峰式命名法
setValue
getValue
checkValue
isValue
16
排版慣例 2
使用 Space 進行縮排
if (Z > B){
a = 1;
b = 2;
c = 3;
d = 4
e = 5;
}
使用 Tab 進行縮
排
if (Z > B){
a = 1;
b = 2;
c = 3;
d = 4
e = 5;
}
→
17
排版慣例 3
永遠都使用大括號將 if 及迴圈語法關起來
if ( Z > B)
PK = True;
else
PK = False;
echo “Shit”;
18
hashOut.data = hashes + SSL_MD5_DIGEST_LEN;
hashOut.length = SSL_SHA1_DIGEST_LEN;
if ((err = SSLFreeBuffer(&hashCtx)) != 0)
goto fail;
if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
19
詞不達意
20
Filter, but filter what ?
filterYear(int year)
select/exclude
21
邊界錯誤
閉區間 ( 包含 / 包含 )
min/max
first/last
半開放區間 ( 包含 / 不包含 )
begin/end
22
布林名稱混亂
Boolean readPassword = true;
↓
Boolean isNeedPassword = true;
Prefix for Boolean : is / has / can / should
23
程式的使用 明書說 - 註解
24
/**
•投資決策系統
•將投資決策獨立拉出的好處是 balabala...
**/
Public void proccessInvestTask(){
if (Z>B){ // 如果利大於弊就去投資
// TODO 老 還要加入核決系統闆說
invest(); // 去投資
// TODO 下次要改名成 printReport();
showReport(); // 這段會將報表印出
}
}
25
if ( B > Z) {
…
}
if ( B < Z) {
…
}
if ( Z > B) {
…
}
if ( Z < B) {
…
}
26
if ( isCheck == true) {
…
}
if ( !isCheck == false) {
…
}
27
不要
看窗外
28
Single Responsibility Principle
單一責任原則
程式可讀性 UP~UP~UP~
解 合耦
降低維護成本
加再用性增 (Resuable)
29
重構、重構再重構
Wiki : 代碼重構( Code refactoring )
指對軟體代碼做任何更動
以 加可讀性增
或者簡化結構
而不影響輸出結果。
30
迷思:可讀性 vs 效率
nameList.contains(“ 王小明” );
nameSet.contains(“ 王小明” );
31
人非聖賢
寫就對了
Just do it!
32
Q & A

training and sharing about clean code

Editor's Notes

  • #2 可以執行、效率好不就好了嗎?
  • #3 天下武功,無堅不破,唯快不破 Q : 什麼快 A : 不是寫的快而是讀的快
  • #4 先承認你就是三個月後的那個『沒有人』 所以這就是為什麼要讓程式碼易讀的原因
  • #5 如何達成人人有功練的理論基礎: 程式碼易於閱讀 學習的成本降低 能看更多的程式碼(誤~) 大喊『有功夫,無懦夫』三次並拿出捐款箱
  • #6 簡單PK一下大家的喜好 不用特別講一行化(後面會講)
  • #7 是閱讀性功能障礙 縮短理解程式碼的時間比減少程式碼行數還重要
  • #8 一行化的隱憂 容易漏看 閱讀不易 容易因順序錯誤增加Debug成本
  • #9 為你心愛的事物取名字 Ex : 汽機車, 竉物
  • #10 IT WORLD : Arg! The 9 hardest things programmers have to do 命名是痛苦的 將近有一半的程式設計師有命名障礙症候群
  • #11 計算一天有幾秒的Method
  • #12 將變數賦與有意義的單字後變的更易閱讀 且更能表達開發者的原意
  • #13 增加一些額外資訊防止誤會產生 案例方享 Timestamp 的seconds 和 millSeconds的誤用
  • #14 命名應具體具體再具體 情境題: 逛街時看到路旁有個紙箱上面寫著….
  • #15 雖然IDE有支援自動補齊 但還是應避免過長的變數名稱以防止閱讀障礙 變數長度適當就好 儘量保持在3個單字內
  • #16 變數使用駝峰式命名法 大駝峰式命名法又稱Pascal命名法,差異是首字就是大寫
  • #17 縮排很重要 使用Tab進行縮排,否則會慘不忍賭
  • #18 上述程式碼原作者想表達的是?? 不閉合很容易造成錯誤 造成別人閱讀上的不便 錯誤發生後Debug不易 需要更細心的追蹤程式碼
  • #19 2014年6月Apple的iOS 7.0.6系統就是因為沒閉合if判斷式而造成重大的資安漏洞SSL協定形同虛設
  • #20 以下介紹一些辭不達意形的範例
  • #21 Filter大家都知道是想表達篩選 面對一個filterYear Method時,到底代表的意思是什麼?
  • #22 邊界極值的通用設計 begin/end在C++裡表半開放區間
  • #23 needPassword到底表示了什麼 需要讀取密碼但未讀取? 2. 密碼已經讀取? 以上容易造成布林混亂
  • #24 註解很重要 怎麼樣寫個好註解是很重要的課題
  • #25 鼓勵加入任何想法的評註 有缺陷或待補的可使用TODO、FIXME或XXX標記來輔助 綠色註解為雞肋註解(一眼就可看出) 改名的註解不應該存在,因為應該要立刻修正
  • #26 在判斷式的世界中,慣用很重要 理解時間很可能是1秒和10秒轉換成本(10倍的差距)
  • #27 If 判斷式的通用法則 優先處理肯定而不是否定 優先處理簡單易理解 優先處理有趣/明顯/重要的情況
  • #28 看有幾個人看窗外? 人們會直覺的連結”看窗外”這個詞 不要會被看窗外掩蓋
  • #29 遵循物件導向設計的單一責任原則 讓一個類別或一個函式只負責一件事也可以有效的提高程式易讀性 更棒的是又能同時擁有解耦和降低維護成本及增加可用性的好處
  • #30 隨時檢視並重構減化你的程式碼(註解也算) 儘量維持程式的小而美 移除經確認後不再使用的程式碼,保持專案的清潔(有待商確,因人而異)
  • #31 有時會為了可讀性犧牲程式效率 亦或有時效率高的方式可讀性低 比較極端的例子 : 低階語言效率高可讀性低 高階語言效率低可讀性高 那倒底該採用那種語言 – by case決定 List.contains -&amp;gt; O(n) Set.contains -&amp;gt; O(1)
  • #32 羅馬也不是一天就造成的 習慣可慢慢培養 設計好就先做 可讀性可利用重構慢慢調整 調整久後就成習慣了