內容簡介
一個好的程式，不僅僅是能得出正確的運行結果，而且還應在其內部保持清晰的代碼邏輯和語義，否則，跟隨在正常結果之後的也許是艱難的代碼維護工作，對程式進行一處修改往往會牽一髮而動全身，一不小心就會埋下深深的陷患。從另一個角度來說，如果每一行代碼的質量都很高，那么這個軟體產品也一定是高質量的。這就像ISO 9000的質量體系認證一樣，與其在產品生產完成之後再進行檢驗，不如控制每一步生產環節的質量。
《更鋒利的C#代碼》由淺入深、由表及里地講述存在於C＃編碼開發中的各種質量問題，讓讀者清楚地了解什麼是應該做的，什麼是不應該做的。C#提供的每種語言機制的功能背後，體現了怎樣的邏輯含義。當遇到具體的問題時，應該如何選擇與取捨。閱讀完此書的每一個章節，都會讓讀者站在更高的角度C#體系擁有更深的認識和把握，不斷向軟體開發的更高層次邁進。
作者簡介
包善東（網名Richard Bao）作者是群碩軟體開發有限公司的一名互動設計師和軟體工程師。9歲時萌生了對編程的濃厚興趣，從此走上了軟體開發的道路，至今已積累了十多年的編程經驗。作者還曾是其學校交響樂團的大提琴兼鋼琴演奏員，在英、法、德、港、台及內地多次進行演出。也許是音樂與藝術思想對編程的滲透，使其在編程中往往善於尋找和諧之美，避免一切生搬硬套。這也許才是《更鋒利的C#代碼》思想的根源吧。
編輯推薦
一個好的程式，不僅僅是能得出正確的運行結果。每個章節的內容似乎都為大家所熟悉，然而視角完全不同。通過對那些幾乎被人們忽視了的細節的精心處理，不斷地提高每一行代碼的質量。它們為什麼必須是，而並非形式主義。C＃提供的每種語言機制的功能背後，體現了怎樣的邏輯含義。讀完此書，你會站在更高的角度與C＃體系擁有更深的認識和把握。
誰能夠讓自己像渾濁的大水一樣安靜下來，慢慢得到澄清？
——《老子》
又有誰能夠從安靜中開始變化，漸漸煥發出生機？
——《老子》
目錄
第1章 基本的代碼風格
1.1 換行的講究
1.1.1 尋找最佳的斷行位置
1.1.2 每行只寫一條語句
1.1.3 分行定義變數
1.2 避免代碼過於擁擠
1.2.1 使用空行分隔代碼塊
1.2.2 使用空格降低代碼密度
1.3如何縮進
1.3.1 嵌套或包含關係引起的縮進
1.3.2 因換行而產生的縮進
1.3.3 使用空格還是Tab鍵
1.4 大括弧
1.4.1 大括弧的位置
1.4.2 空的大括弧結構
1.4.3 僅包含單個語句的結構體
1.5 保持項目檔案的條理性
1.5.1 解決方案的結構呼應
1.5.2 代碼檔案的結構
1.5.3 使用#region標記來隱藏細節
第2章 養成良好的注釋習慣
2.1 何時需要注釋
2.1.1 解釋代碼的意圖
2.1.2 對局部變數的說明
2.1.3 充當代碼標題
2.1.4 指出例外情況
2.1.5 開發過程的提示
2.2 注釋的格式
2.2.1 單行注釋
2.2.2 多行注釋
2.3 正確使用XML文檔注釋
2.3.1 結構與類的XML文檔注釋
2.3.2 屬性的XML文檔注釋
2.3.3 方法的XML文檔注釋
2.3.4 構造函式的XML文檔注釋
2.3.5 事件的XML文檔注釋
2.3.6 枚舉類型的XML文檔注釋
2.3.7 泛型的XML文檔注釋
2.3.8 其他標記
第3章一般命名規範
3.1 選用合適的名稱
3.1.1 使用字元的限制
3.1.2 使用含義明確的英語
3.2 大小寫規則
3.2.1 Pascal規則
3.2.2 Camel規則
3.2.3 首字母縮寫詞與簡寫詞
3.2.4 應在何時使用何種大小寫規則
3.3 考慮跨語言編程
3.3.1 不要通過大小寫區分標識符
3.3.2 避免與其他語言的關鍵字重複
3.3.3 避免使用特定語言的術語
3.4 命名一致與衝突
3.4.1 大小寫無關原則
3.4.2 對基類型的命名暗示
3.4.3 對參數與屬性的關係暗示
3.4.4 屬性名稱與自身類型同名
3.4.5 與命名空間相關的命名衝突
3.5 匈牙利命名法
3.5.1 匈牙利命名法的弊端
3.5.2 考慮為控制項套用匈牙利命名法
第4章處理數據
4.1 關於數據類型
4.1.1 整數
4.1.2 浮點數
4.1.3 布爾類型
4.1.4 字元與字元串
4.2 變數的使用
4.2.1 儘可能使用內置關鍵字
4.2.2初始化一切變數
4.2.3 集中使用變數
4.3 使用枚舉
4.3.1 何時使用枚舉
4.3.2 如何為枚舉命名
4.3.3 關於枚舉項
4.3.4 標記枚舉
4.4 魔數——以字面數值出現在代碼中的常量
4.5 複雜的表達式
4.5.1 運算符的副作用
4.5.2簡化表達式
第5章分支結構
5.1 使用if結構
5.1.1“==”與“=”的問題
5.1.2 如何處理複雜的條件
5.2 使用switch結構
5.2.1 break語句
5.2.2 使用default子句要注意的問題
5.3 選擇if還是switch?
5.4 關於判斷順序的設計
5.4.1 先判斷最有可能成立的條件
5.4.2 預防因條件短路而丟失操作
5.5 慎用goto語句
第6章 循環結構
6.1 使用for還是while
6.1.1 for和while的語義比較
6.1.2 簡單的數值疊代——for和while的思維模式的差j
6.1.3 預知循環次數——微波爐加熱的啟示
6.1.4 集合疊代——獨特的foreach結構
6.2 循環變數的使用
6.2.1 循環變數的命名
6.2.2 循環變數的定義
6.2.3 避免循環變數的非常規套用
6.3 提高循環效率
6.3.1 避免不必要的重複勞動
6.3.2 避免不必要的循環
第7章 如何使用函式
7.1 為什麼要使用函式
7.1.1 函式與方法
7.1.2 代碼復用
7.1.3 隱藏細節——使用函式進行抽象
7.2 函式重載
7.2.1 重載的語義——為調用者提供方便
7.2.2 保持核心代碼唯一
7.3 參數的設計
7.3.1 參數的命名
7.3.2 不要使用保留項.
7.3.3 何時使用變長參數列表
7.3.4 何時使用ref參數和out參數
7.3.5參數的順序
7.3.6 重載函式的參數一致性體現
7.4 參數檢查的必要性
7.4.1 檢查零值及空引用
7.4.2 檢查枚舉類型
7.4.3 防止數據被篡改
7.4.4 在何處檢查合法性
7.5 函式的出口——離開函式的三種方式
7.5.1 返回值的用法
7.5.2 離開函式的時機
第8章 結構與類
8.1 結構與類的比較
8.1.1 值類型與引用類型
8.1.2 何時應當使用結構
8.1.3 何時應當使用類
8.2 結構與類的命名
8.2.1 措辭
8.2.2 避免與命名空間衝突
8.2.3 不要使用“C”前綴
8.2.4後綴的使用
8.3 如何搭建一個典型的結構
8.3.1 找準核心數據
8.3.2 數據的表現形式
8.3.3 定義等價原則
8.3.4實現基本運算
8.4 如何真正面向對象
第9章 封裝
9.1 構造函式
9.1.1 構造函式的語義
9.1.2 何時使用靜態構造方法
9.1.3 構造函式的參數及其初始化
9.2 finalize函式
9.2.1 垃圾回收器
9.2.2 IDisposable接口——顯式釋放資源的方法
9.2.3 釋放資源的一般範式
9.3 何時應該使用欄位
9.3.1 存儲核心數據
9.3.2 維持中間結果
9.3.3 常量欄位
9.4 如何使用欄位
9.4.1 欄位的命名
9.4.2 訪問控制
9.5 何時應該使用屬性
9.5.1 屬性的語義
9.5.2 數據訪問控制
9.5.3 需要的後續操作
9.5.4 簡單的數據處理
9.5.5 預定義的對象實例
9.6 如何使用屬性
9.6.1 屬性的命名
9.6.2 訪問控制
9.6.3 提供合理的默認值
9.6.4 保持輕量級的操作
9.6.5 在屬性中拋出異常
9.7 何時應該使用方法
9.7.1 表示某種操作
9.7.2 耗時的任務——方法在形式上的暗示作用
9.7.3 有副作用的操作
9.7.4 返回不確定的值
9.7.5 返回數組或集合對象
9.8 如何使用方法
9.8.1 方法的命名
9.8.2 檢查傳入的參數
9.9 靜態類型及成員
9.10 嵌套類型及其適用場合
9.11 可變類型的安全性
9.12 使用程式集與命名空間
9.12.1 程式集的劃分
9.12.2 為什麼要使用命名空間
9.12.3 命名空間的命名
9.12.4 命名空間的管理
第10章 繼承與多態
10.1 如何利用類繼承
10.1.1 自上而下逐步細化
10.1.2 自下而上逐步抽象
10.2 繼承限制
10.2.1 強制繼承的抽象類型
10.2.2 密封類型
10.2.3 擴展方法——直接向已有類型添加功能
10.3 關於接口
10.3.1 接口的語義
10.3.2 接口的命名
10.3.3 使用接口還是類繼承
10.4 何時應當顯式實現接口
10.4.1 解決接口之間的命名衝突
1 0.4.2 提供強類型操作
10.4.3 隱藏僅用於通過接口訪問的成員
10.5 使用多態
10.5.1 何時應進行重寫
10.5.2 應當重寫哪個成員
10.5.3 保持參數名稱一致
10.6運算符重載
10.6.1 可重載的運算符
10.6.2 符合運算符的本意
10.6.3 運算符的關聯性
10.6.4 類型轉換運算符的重載
第11章 泛型機制
11.1 裝箱與取消裝箱
11.2 何時使用泛型
11.3 泛型的類型參數設計
11.3.1 類型參數的命名
11.3.2 使用類型參數的時機
第12章 事件與委託
12.1 何為事件驅動模式
12.2 如何回響事件
12.2.1 事件處理函式
12.2.2代碼的分配
12.2.3 事件偵聽器的使用
12.3如何提供事件
12.3.1 何時應當提供事件
12.3.2 事件的命名
12.3.3 傳遞與事件相關的數據
12.3.4 用於事件的委託及其要遵守的約定
12.3.5 觸發事件
12.4 使用委託
12.4.1 何時使用委託
12.4.2 何時使用匿名方法
12.4.3 基類型與派生類型
第13章 集合類型
13.1 系統內置集合類型
13.1.1 數組
13.1.2 列表
13.1.3 字典
13.1.4 其他類型
13.2 選用適當的集合類型要考慮的幾個方面
13.2.1 容量
13.2.2進出次序
13.2.3 定位的問題——索引／鍵訪問
13.2.4 元素結構
13.2.5 排序
13.3 性能比較
13.4 提供自己的集合類型
13.4.1 何時應提供集合類型
13.4.2 集合類型的命名
13.4.3 提供與內置集合類型一致的行為
13.4.4 索引器及其應遵守的規則
13.4.5 疊代器
第14章 LINQ查詢
14.1 提高LINQ查詢的效率
14.1.1 查詢語法和方法語法的區別
14.1.2 LINQ查詢的創建、執行與性能
14.1.3 減少返回的數據量
14.2 LINQ中的錯誤處理一一採用防禦式編程
14.3 LINQ查詢的相關機制
14.3.1 匿名類型
14.3.2 隱式類型的局部變數
14.3.3 Lambda表達式與匿名函式
第15章 異常
15.1 處理異常時應遵守的規範
15.2 拋出異常
15.2.1 異常的語義
15.2.2 不應使用異常的位置
15.2.3 控制異常
15.2.4 異常的重新拋出——重新包裝時要注意的
15.3 選用合適的異常類型
15.3.1 常見的異常類型
15.3.2 不應使用的異常類型
15.4 異常提示信息
15.5 設計自定義異常及應遵循的約定
第16章 全球化與本地化
16.1 分離與特定區域相關的信息
16.2 處理特定區域性的數據
16.2.1 區分區域性與界面區域性
16.2.2 在內部使用Unicode
16.2.3 文本的比較與排序
16.2.4 不要假定區域性的行為
16.3 何時使用固定區域性
16.4 用戶界面應注意的細節
16.4.1 使用資源
16.4.2 術語
16.4.3 界面布局
16.4.4 歧義
16.4.5 組合文本
附錄A：C#、VB、NET、J#關鍵字表
附錄B：常用的異常類型
序言
這是一本以C#語言為基礎，著眼於代碼質量的編程指導。雖然沒有磚頭書的厚重，但卻匯集了許許多多開發人員大量的實踐經驗。每個章節的內容似乎都為大家所熟悉，然而視角卻完全不同，通過對那些幾乎被人們忽視了的細節的精心處理，不斷地提高每一行代碼的質量。相信無論是C#初學者，還是具有NET經驗的開發人員，都能從本書中得到啟發，寫出質量更好的代碼，開發出更加專業的程式。
為什麼要寫這本書？
很多人在編程時，僅僅追求其可以運行出正確的結果。這也許與學校中長期的數學式的編程教學方式有關，教學中涉及的都是一些局部問題，即使有完整的程式，規模也非常有限，通常只考慮理想狀況下算法與邏輯的正確性，很少去全面地考察它的工程質量。然而，當軟體開發成為一種工業時，團隊成員之間的高效合作成為首要的因素。任何一個具有一定規模的軟體公司都深知：軟體的工程質量往往比代碼的算法效率更為重要。而現代化的質量管理並非僅僅是對產品的檢驗，更多的來自於過程的質量控制--用最佳的方式編寫每一行代碼，確保每一行代碼都是高質量的。
可惜的是，涉及這方面知識的著作並不多，即使提及，也只是非常膚淺的一些關於縮進之類的書寫格式上的建議。深入到代碼之間的語義與邏輯關係層面，專門闡述代碼質量的書可謂是鳳毛麟角。難得的幾部專著也大多是以C／C++語言為主，很多規則及其背後的理由對於C孝語言及．NET類庫設計並不適用，讀者在使用C＃中的許多新特性（如索引器、事件、委託、異常等）之時也無法得到針對性的指導與幫助。本書不但緊密地結合了C#自身的特點，給出了豐富的原則性指導並進行了詳細的解釋，而且更具有實用操作性。
什麼樣的人應該讀這本書？
本書雖然遍及C＃的各種語法現象，但目的並不在於語言本身的教學，而是幫助讀者發現那些影響代碼質量的細節，並著手進行改進。對於初學者來說，可以配合相關的C＃教材一同閱讀；對於有經驗的C#使用者來說，則可以作為一本開發過程中的手邊參考。
書摘
第1章 基本的代碼風格
假設我們寫的是文章而不是程式，那么你一定覺得諸如文章應該分為若干個自然段、每段開頭空兩格之類的規則是理所當然的。如果段落的開頭不空兩格，或者乾脆把整個文章寫成單獨的一段，仔細想來似乎也不會影響文章實質內容的表達。既然如此，我們為什麼還要在形式上下功夫呢？構想一下，如果你手中的這本書既無章節也無目錄，正文中的不同內容都使用同樣的字型字號印刷，幾百頁紙從頭至尾洋洋灑灑如念經般地“一氣呵成”，你還有耐心看下去嗎？
這是一個人人都能理解的道理，可是當文章變成程式的時候，就不是每個人都能想得通的了。不僅僅是初學者，甚至一些熟練的開發人員，也會寫出凌亂不堪的代碼。許多人一定有過這樣的經歷：一年半載之後，自己原來寫的程式就完全看不懂了。如果這段程式只是為了交作業，或者臨時一用，那還可以不去追究，但如果這是一個商業軟體，現在需要根據客戶的要求進行修改的話，工作量可就大了——你不得不先花時間把你原來的思路看懂。
肯定會有人反駁：代碼是給機器運行的，又不是給人看的，寫那么好看有什麼用？
線上試讀部分章節 第1章 基本的代碼風格
假設我們寫的是文章而不是程式，那么你一定覺得諸如文章應該分為若干個自然段、每段開頭空兩格之類的規則是理所當然的。如果段落的開頭不空兩格，或者乾脆把整個文章寫成單獨的一段，仔細想來似乎也不會影響文章實質內容的表達。既然如此，我們為什麼還要在形式上下功夫呢？構想一下，如果你手中的這本書既無章節也無目錄，正文中的不同內容都使用同樣的字型字號印刷，幾百頁紙從頭至尾洋洋灑灑如念經般地“一氣呵成”，你還有耐心看下去嗎？
這是一個人人都能理解的道理，可是當文章變成程式的時候，就不是每個人都能想得通的了。不僅僅是初學者，甚至一些熟練的開發人員，也會寫出凌亂不堪的代碼。許多人一定有過這樣的經歷：一年半載之後，自己原來寫的程式就完全看不懂了。如果這段程式只是為了交作業，或者臨時一用，那還可以不去追究，但如果這是一個商業軟體，現在需要根據客戶的要求進行修改的話，工作量可就大了——你不得不先花時間把你原來的思路看懂。
肯定會有人反駁：代碼是給機器運行的，又不是給人看的，寫那么好看有什麼用？
他的話只對了前半句：代碼確實是給機器運行的，可是機器總共才需要看它幾分鐘？你花一個月編寫的程式，機器頂多兩三分鐘就編譯好了——在這兩三分鐘之前，這代碼不都是你在看嗎？開發軟體編寫代碼不是一朝一夕的事情，更多的情況下，一個軟體的開發要經歷很長的時間，並且常常由多人合作完成。一個龐大的軟體項目，可能會動用上千名程式設計師工作數年！如果把代碼寫得連自己都看不明白，怎么與別人交流？同一個開發團隊內，一定要保持良好且一致的代碼風格，才能最大化地提高開發效率。
有的初學者會問：我現在只是一個人寫程式，並不需要和其他人合作，這些條條框框還有什麼必要嗎？
要知道，團隊協作只是一個方面。我經常遇到這類情況，一些初學者拿著他的程式來說：“這個怎么不能編譯？”我幫他把代碼整理了半天，發現有一個地方丟了半個大括弧。如果他寫程式的時候能夠稍加注意一些的話，相信此類錯誤完全可以避免。保持良好的編程習慣，能夠避免的錯誤還遠不止這些。
……
