Nullable or Empty
今天是要說
(1) if ( FunctionA() == null )
(2) if( FunctionA() == string.Empty )
在我大腦裡頭的設計原則依序如下:
1. 減少bug
2. 增加可讀性
3. 提昇效能
後來又增加了一項: 易單元測試
至於是程序導向, 物件導向 甚至是服務導向
則沒有一定準則 (case by case).
也因為要減少bug, 所以系統內風格的一致性, 變得很重要,
在開始一個系統時, 通常要跟團隊溝通好,
"不要給我回傳 null" "為此付出效能也不打緊" <- 因為不是做device, 所以可以任性
因此, 如果是自己own的方案, 通常不會有什麼問題.
但如果要維護別人的程式, 倒是吃了不少暗虧,
有的PG性情多變, (自己曾經也是, 其實也不太好意思說人家)
有時回傳null, 有時回傳空白,
有時回傳null, 有時回傳空集合 ... Orz
當我自以為是用 if( string.Empty.Equals(FunctionA()) ) 時卻發現FunctionA回傳 null ...
不知道為什麼每次遇到這種, 除錯都會花很多時間, 可能是我預設立場, 它不會給我null.
而幾個比較常見的：
string 可以null 也可以empty 也可以是Trim()是empty
Nullable 讓各種型別可以null
如:int, DateTime …
DBNull 是物件不是null (這個概念很不錯, 用一個常數來代表null)
Collection 可是null 也可以是空集合(會付出一些效能)
當然, 有時雖然講好了, 但發生一些案例時, 仍不可避免的得回傳null,
這方面只能用比較消極的辦法, 請伙伴記得在Function前的註解, 一定要標明.
最後, 積極的做法, 只要在Unit Test 加入Null 的test case自然可以避掉因Null造成的麻煩,
但每一個 Function 都要考慮 Null 或如果 沒有Unit Test要從頭刻的話, 也是蠻煩人的工作.
後記: 感覺這一切都是自己很懶造成的 ...