如果非期望值是問題所在的話，那麼我們就應該努力消除它們。儘管我們幾乎從未期望過null（空），然而型別系統卻強迫我們裝出一副很需要它的樣子。——craig
儘管這句話已經被.net開發者在這些年來講過無數次。然而修正此問題並非易事，不僅僅是在變數上拍個屬性或其他修飾那麼簡單。更嚴峻的挑戰之一就是，要是t為非可空引用型別的話，那麼default該如何處理。craig寫道，
這裡的根本問題在於c#中根深蒂固的假設：該假設即每種型別都有預設值。試想一下：如果在題為非可空型別對c#：修正十億美元的錯誤的文章中，craig引入了兩個新概念：t沒有（或可能沒有獲得）預設值，那麼編譯器在計算default(t)、初始化型別t的字段、或初始化某個型別t的新陣列中的陣列項時就會無值可用。由於一談到非可空引用型別就會涉及此問題，儘管某些引用型別擁有適當的非空預設值（例如非空字串型別的預設值可能是空字串），然而對於大多數引用型別而言卻並非如此。試想一下：ienumerator的預設非空值是什麼？iobservable呢？usercontrol呢？networkstream呢？答案很簡單，它們沒有任何預設非空值。而你能做的最好方法就是，給出某種模仿例項，即一旦你嘗試使用該例項就會導致失敗……不過我們已經有了那種例項，並稱之為null（空）。
要是需要構建私有欄位或陣列，就將其型別宣告為withdefault(t)，而不是型別t。然後在讀取該字段或陣列時，可以將其重新強制轉換非可空型別t。這種強制轉換本身是不安全的，而且倘若沒有正確構造就有可能丟擲異常，不過一旦成為了非空，開發者便可如魚得水。要了解這樣做所產生的後果，最好還是通過craig文章中的例子來解釋。
如果對此主題有興趣，可以在使用者反饋**上對非空引用型別的建議進行投票。
關於C 中非可空型別的一點建議
如果非期望值是問題所在的話，那麼我們就應該努力消除它們。儘管我們幾乎從未期望過null 空 然而型別系統卻強迫我們裝出一副很需要它的樣子。craig 儘管這句話已經被.net開發者在這些年來講過無數次。然而修正此問題並非易事，不僅僅是在變數上拍個屬性或其他修飾那麼簡單。更嚴峻的挑戰之一就是，要是t為...
關於SQL優化的一點建議
前段時間一直在做關於效能優化相關的工作，結合自己的實際工作經驗，只針對sql層面提一些優化的規範和建議。1 單條sql長度不宜超過100行 2 sql子查詢不宜巢狀3層 子查詢巢狀過多，又可能會導致解析過於複雜，產生錯誤的執行計畫 3 sql表關聯需要考慮連線和限制條件的索引 4 同一模組避免出現大...
c 的可空型別
t variablet 可空型別的基本型別，variable 表示可空型別的變數，表示可空型別 如果未賦初值，則判定為null 可空型別包含hasvalue和value兩個屬性 其中hasvalue為bool，value為該例項的值 可空型別的例項只包含乙個方法 getvalueordefault ...