第十七章-異常控制結構
使用保護子句簡化複雜的錯誤處理
if (checkUserName() == true)
{
if (checkPassword() == true)
{
if (checkBirthday() == true)
{
if (checkCertificationPhoto() == true)
{
// lots of code.
}
}
}
}
改寫為
if (checkUserName() == false)
{
/* 可加上錯誤提示. */
return;
}
if (checkPassword() == false)
{
/* 可加上錯誤提示. */
return;
}
if (checkBirthday() == false)
{
/* 可加上錯誤提示. */
return;
}
if (checkCertificationPhoto() == false)
{
/* 可加上錯誤提示. */
return;
}
/* 通過以上重重考驗才能抵達此處. */
// lots of code.
前者若要加上錯誤提示,又會產生出一堆 else 區塊. 後者則不會降低閱讀性. 不過 return 應該要小心使用就是. Orz
謹慎使用 goto
以下引述自書中:
使用 goto 會違反程式碼應該完全由上而下流動的原則.
我自己在考古別人的程式碼時,也最討厭看到跳來跳去的邏輯,總之謹慎使用會改變程式碼流程的語法.
第十八章-資料表導向法
書上先是舉了個取出每個月天數的範例,與其在程式中寫出以下程式碼:
if (month = 1)
{
return 31;
}
else if (month = 2)
{
return 28;
}
...
..(落落長的程式碼)..
...
else if (month = 12)
{
return 31;
}
不如直接建立一個每月天數的陣列,也就是一個存在於記體的資料表,直接查表就不需要寫出一長串無聊的條件判斷了.
int[] daysOfMonth =
{31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
int daysOfJuly = daysOfMonth[7 - 1]; // 直接查表. 此處可以搬出成一個常式,來處理 -1 的邏輯.
看完這例子,我只覺得超簡單,這樣也能寫成一章. 書上接著舉了一個 "彈性訊息格式" 的範例,我只能說 "我錯了!!",我對這個範例一點 Sence 都沒有啊. 囧rz
有興趣的人請自己翻書來看,以下心得請不要認真看,算是自己解釋給自己看的東西,完全不知道正不正確.
系統內有 20 種資訊格式,因為每種資訊內的欄位都不一樣,書中將 "如何解讀資訊" 的動作包裝出來:
Hard cord: 類似每月取天數的例子,一種解讀資訊的方法就寫在一個 if 裡頭.
OOP: 建立一個解讀資訊的繼承樹,或是使用 Strategy Pattern 來封裝不同的解讀方式.
好戲上場. Orz
資料表:
1. 先定義出欄位會出現哪些型別(int, String...).
2. 利用 1 定義出的型別,建立每種資訊用來解讀的 meta data,系統內會有 20 個這樣的 meta data,這些 meta data 集合就是一個資料表(可以存在檔案內).
3. 建立讀取欄位型別的共用常式.
4. 系統接收到一個資訊,它就根據資訊編號去資料表找出對應的 meta data,然後透過 3 建立的常式就能解讀資訊.
好處是若又有新的資訊,我們不用更動程式碼,只需要在資料表建立新的 meta data. 程式碼變少了,因為都轉成 meta data(但我還是要寫 囧).
我承認,這章我看得超痛苦,我對含有 meta-data 這種例子的東西真的很不行. 我覺得我之後又會忘光光了. Orz
第十九章-一般性控制問題
以隱含的方式將布林式作真及假
不要寫 while (isDone == false) 而寫成 while (!isDone) .
不要寫 while ((a > b) == true) 而寫成 while (a > b).
這樣的好處是不用記太多項數,讀起來也較像是對話式的英文. 不過我忘記我在哪裡看到,最好不要在在條件判斷中使用 "!" .
while (!isDone) // 我看這句腦中是浮現 while ((!isDone) == true) , 反而更亂.
while (isDone == false) // 我很直覺就把 isDone 想成變數,它要等於 false 才會執行.
反而我覺得看個人啦,我思考方式比較像電腦,念起來順不順不重要,我只關心 isDone 是一個變數,它要等於 false 才會執行. Orz
以數線順序編寫數字運算式
(MIN <= i && i <= MAX)
(i >= MIN && MAX >= i)
哪一個看起來比較有感覺? 哪一個一看就知道 i 的範圍?
---- MIN ---- i ---- MAX ----
這樣還看不出來? 那這一個重點你可以跳過. Orz
書上有一段話我覺得很不賴,跟大家共勉之.
寧可努力找出好的解決方法並避開失敗,也不要嘗試找出最佳的解決辦法.
又找到了個偷懶的好理由了. Orz
0 則回應: