更鋒利的C#代碼

前言

　　這是一本以C#語言為基礎，著眼于代碼質量的編程指導。雖然沒有磚頭書的厚重，但卻匯集了許許多多開發(fā)人員大量的實踐經(jīng)驗。每個章節(jié)的內容似乎都為大家所熟悉，然而視角卻完全不同，通過對那些幾乎被人們忽視了的細節(jié)的精心處理，不斷地提高每一行代碼的質量。相信無論是C#初學者，還是具有NET經(jīng)驗的開發(fā)人員，都能從本書中得到啟發(fā)，寫出質量更好的代碼，開發(fā)出更加專業(yè)的程序。

內容概要

　　《更鋒利的C#代碼：編寫高質量C#程序》由淺入深、由表及里地講述存在于C＃編碼開發(fā)中的各種質量問題，讓讀者清楚地了解什么是應該做的，什么是不應該做的。C#提供的每種語言機制的功能背后，體現(xiàn)了怎樣的邏輯含義。當遇到具體的問題時，應該如何選擇與取舍。閱讀完此書的每一個章節(jié)，都會讓讀者站在更高的角度C#體系擁有更深的認識和把握，不斷向軟件開發(fā)的更高層次邁進。一個好的程序，不僅僅是能得出正確的運行結果，而且還應在其內部保持清晰的代碼邏輯和語義，否則，跟隨在正常結果之后的也許是艱難的代碼維護工作，對程序進行一處修改往往會牽一發(fā)而動全身，一不小心就會埋下深深的陷患。從另一個角度來說，如果每一行代碼的質量都很高，那么這個軟件產(chǎn)品也一定是高質量的。這就像ISO9000的質量體系認證一樣，與其在產(chǎn)品生產(chǎn)完成之后再進行檢驗，不如控制每一步生產(chǎn)環(huán)節(jié)的質量。

作者簡介

　　包善東（網(wǎng)名Richard Bao），群碩軟件開發(fā)有限公司的一名交互設計師和軟件工程師。9歲時萌生了對編程的濃厚興趣，從此走上了軟件開發(fā)的道路，至今已積累了十多年的編程經(jīng)驗。作者還曾是其學校交響樂團的大提琴兼鋼琴演奏員，在英、法、德、港、臺及內地多次進行演出。也許是音樂與藝術思想對編程的滲透，使其在編程中往往善于尋找和諧之美，避免一切生搬硬套。這也許才是《更鋒利的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 因換行而產(chǎn)生的縮進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標記來隱藏細節(jié)第2章 養(yǎng)成良好的注釋習慣2.1 何時需要注釋2.1.1 解釋代碼的意圖2.1.2 對局部變量的說明2.1.3 充當代碼標題2.1.4 指出例外情況2.1.5 開發(fā)過程的提示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 構造函數(shù)的XML文檔注釋2.3.5 事件的XML文檔注釋2.3.6 枚舉類型的XML文檔注釋2.3.7 泛型的XML文檔注釋2.3.8 其他標記第3章一般命名規(guī)范3.1 選用合適的名稱3.1.1 使用字符的限制3.1.2 使用含義明確的英語3.2 大小寫規(guī)則3.2.1 Pascal規(guī)則3.2.2 Camel規(guī)則3.2.3 首字母縮寫詞與簡寫詞3.2.4 應在何時使用何種大小寫規(guī)則3.3 考慮跨語言編程3.3.1 不要通過大小寫區(qū)分標識符3.3.2 避免與其他語言的關鍵字重復3.3.3 避免使用特定語言的術語3.4 命名一致與沖突3.4.1 大小寫無關原則3.4.2 對基類型的命名暗示3.4.3 對參數(shù)與屬性的關系暗示3.4.4 屬性名稱與自身類型同名3.4.5 與命名空間相關的命名沖突3.5 匈牙利命名法3.5.1 匈牙利命名法的弊端3.5.2 考慮為控件應用匈牙利命名法第4章處理數(shù)據(jù)4.1 關于數(shù)據(jù)類型4.1.1 整數(shù)4.1.2 浮點數(shù)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 魔數(shù)——以字面數(shù)值出現(xiàn)在代碼中的常量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還是switch5.4 關于判斷順序的設計5.4.1 先判斷最有可能成立的條件5.4.2 預防因條件短路而丟失操作5.5 慎用goto語句第6章 循環(huán)結構6.1 使用for還是while6.1.1 for和while的語義比較6.1.2 簡單的數(shù)值迭代——for和while的思維模式的差j6.1.3 預知循環(huán)次數(shù)——微波爐加熱的啟示6.1.4 集合迭代——獨特的foreach結構6.2 循環(huán)變量的使用6.2.1 循環(huán)變量的命名6.2.2 循環(huán)變量的定義6.2.3 避免循環(huán)變量的非常規(guī)應用6.3 提高循環(huán)效率6.3.1 避免不必要的重復勞動6.3.2 避免不必要的循環(huán)第7章 如何使用函數(shù)7.1 為什么要使用函數(shù)7.1.1 函數(shù)與方法7.1.2 代碼復用7.1.3 隱藏細節(jié)——使用函數(shù)進行抽象7.2 函數(shù)重載7.2.1 重載的語義——為調用者提供方便7.2.2 保持核心代碼唯一7.3 參數(shù)的設計7.3.1 參數(shù)的命名7.3.2 不要使用保留項.7.3.3 何時使用變長參數(shù)列表7.3.4 何時使用ref參數(shù)和out參數(shù)7.3.5參數(shù)的順序7.3.6 重載函數(shù)的參數(shù)一致性體現(xiàn)7.4 參數(shù)檢查的必要性7.4.1 檢查零值及空引用7.4.2 檢查枚舉類型7.4.3 防止數(shù)據(jù)被篡改7.4.4 在何處檢查合法性7.5 函數(shù)的出口——離開函數(shù)的三種方式7.5.1 返回值的用法7.5.2 離開函數(shù)的時機第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 找準核心數(shù)據(jù)8.3.2 數(shù)據(jù)的表現(xiàn)形式8.3.3 定義等價原則8.3.4實現(xiàn)基本運算8.4 如何真正面向對象第9章 封裝9.1 構造函數(shù)9.1.1 構造函數(shù)的語義9.1.2 何時使用靜態(tài)構造方法9.1.3 構造函數(shù)的參數(shù)及其初始化9.2 Finalize函數(shù)9.2.1 垃圾回收器9.2.2 IDisposable接口——顯式釋放資源的方法9.2.3 釋放資源的一般范式9.3 何時應該使用字段9.3.1 存儲核心數(shù)據(jù)9.3.2 維持中間結果9.3.3 常量字段9.4 如何使用字段9.4.1 字段的命名9.4.2 訪問控制9.5 何時應該使用屬性9.5.1 屬性的語義9.5.2 數(shù)據(jù)訪問控制9.5.3 需要的后續(xù)操作9.5.4 簡單的數(shù)據(jù)處理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 返回數(shù)組或集合對象9.8 如何使用方法9.8.1 方法的命名9.8.2 檢查傳入的參數(shù)9.9 靜態(tài)類型及成員9.10 嵌套類型及其適用場合9.11 可變類型的安全性9.12 使用程序集與命名空間9.12.1 程序集的劃分9.12.2 為什么要使用命名空間9.12.3 命名空間的命名9.12.4 命名空間的管理第10章 繼承與多態(tài)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 何時應當顯式實現(xiàn)接口10.4.1 解決接口之間的命名沖突10.4.2 提供強類型操作10.4.3 隱藏僅用于通過接口訪問的成員10.5 使用多態(tài)10.5.1 何時應進行重寫10.5.2 應當重寫哪個成員10.5.3 保持參數(shù)名稱一致10.6運算符重載10.6.1 可重載的運算符10.6.2 符合運算符的本意10.6.3 運算符的關聯(lián)性10.6.4 類型轉換運算符的重載第11章 泛型機制11.1 裝箱與取消裝箱11.2 何時使用泛型11.3 泛型的類型參數(shù)設計11.3.1 類型參數(shù)的命名11.3.2 使用類型參數(shù)的時機第12章 事件與委托12.1 何為事件驅動模式12.2 如何響應事件12.2.1 事件處理函數(shù)12.2.2代碼的分配12.2.3 事件偵聽器的使用12.3如何提供事件12.3.1 何時應當提供事件12.3.2 事件的命名12.3.3 傳遞與事件相關的數(shù)據(jù)12.3.4 用于事件的委托及其要遵守的約定12.3.5 觸發(fā)事件12.4 使用委托12.4.1 何時使用委托12.4.2 何時使用匿名方法12.4.3 基類型與派生類型第13章 集合類型13.1 系統(tǒng)內置集合類型13.1.1 數(shù)組13.1.2 列表13.1.3 字典13.1.4 其他類型13.2 選用適當?shù)募项愋鸵紤]的幾個方面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 索引器及其應遵守的規(guī)則13.4.5 迭代器第14章 LINQ查詢14.1 提高LINQ查詢的效率14.1.1 查詢語法和方法語法的區(qū)別14.1.2 LINQ查詢的創(chuàng)建、執(zhí)行與性能14.1.3 減少返回的數(shù)據(jù)量14.2 LINQ中的錯誤處理一一采用防御式編程14.3 LINQ查詢的相關機制14.3.1 匿名類型14.3.2 隱式類型的局部變量14.3.3 Lambda表達式與匿名函數(shù)第15章 異常15.1 處理異常時應遵守的規(guī)范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 分離與特定區(qū)域相關的信息16.2 處理特定區(qū)域性的數(shù)據(jù)16.2.1 區(qū)分區(qū)域性與界面區(qū)域性16.2.2 在內部使用Unicode16.2.3 文本的比較與排序16.2.4 不要假定區(qū)域性的行為16.3 何時使用固定區(qū)域性16.4 用戶界面應注意的細節(jié)16.4.1 使用資源16.4.2 術語16.4.3 界面布局16.4.4 歧義16.4.5 組合文本附錄A：C#、VB.NET、J#關鍵字表附錄B：常用的異常類型

章節(jié)摘錄

　　第1章基本的代碼風格　　假設我們寫的是文章而不是程序，那么你一定覺得諸如文章應該分為若干個自然段、每段開頭空兩格之類的規(guī)則是理所當然的。如果段落的開頭不空兩格，或者干脆把整個文章寫成單獨的一段，仔細想來似乎也不會影響文章實質內容的表達。既然如此，我們?yōu)槭裁催€要在形式上下功夫呢？設想一下，如果你手中的這本書既無章節(jié)也無目錄，正文中的不同內容都使用同樣的字體字號印刷，幾百頁紙從頭至尾洋洋灑灑如念經(jīng)般地“一氣呵成”，你還有耐心看下去嗎？　　這是一個人人都能理解的道理，可是當文章變成程序的時候，就不是每個人都能想得通的了。不僅僅是初學者，甚至一些熟練的開發(fā)人員，也會寫出凌亂不堪的代碼。許多人一定有過這樣的經(jīng)歷：一年半載之后，自己原來寫的程序就完全看不懂了。如果這段程序只是為了交作業(yè)，或者臨時一用，那還可以不去追究，但如果這是一個商業(yè)軟件，現(xiàn)在需要根據(jù)客戶的要求進行修改的話，工作量可就大了——你不得不先花時間把你原來的思路看懂。　　肯定會有人反駁：代碼是給機器運行的，又不是給人看的，寫那么好看有什么用？　　他的話只對了前半句：代碼確實是給機器運行的，可是機器總共才需要看它幾分鐘？你花一個月編寫的程序，機器頂多兩三分鐘就編譯好了——在這兩三分鐘之前，這代碼不都是你在看嗎？開發(fā)軟件編寫代碼不是一朝一夕的事情，更多的情況下，一個軟件的開發(fā)要經(jīng)歷很長的時間，并且常常由多人合作完成。一個龐大的軟件項目，可能會動用上千名程序員工作數(shù)年！如果把代碼寫得連自己都看不明白，怎么與別人交流？同一個開發(fā)團隊內，一定要保持良好且一致的代碼風格，才能最大化地提高開發(fā)效率?！　∮械某鯇W者會問：我現(xiàn)在只是一個人寫程序，并不需要和其他人合作，這些條條框框還有什么必要嗎？　　要知道，團隊協(xié)作只是一個方面。我經(jīng)常遇到這類情況，一些初學者拿著他的程序來說：“這個怎么不能編譯？”我?guī)退汛a整理了半天，發(fā)現(xiàn)有一個地方丟了半個大括號。如果他寫程序的時候能夠稍加注意一些的話，相信此類錯誤完全可以避免。保持良好的編程習慣，能夠避免的錯誤還遠不止這些。

編輯推薦

　　《更鋒利的C#代碼：編寫高質量C#程序》由清華大學出版社出版?！　∫粋€好的程序，不僅僅是能得出正確的運行結果。每個章節(jié)的內容似乎都為大家所熟悉，然而視角完全不同。通過對那些幾乎被人們忽視了的細節(jié)的精心處理，不斷地提高每一行代碼的質量。它們?yōu)槭裁幢仨毷牵⒎切问街髁x。C＃提供的每種語言機制的功能背后，體現(xiàn)了怎樣的邏輯含義。讀完此書，你會站在更高的角度與C＃體系擁有更深的認識和把握。

圖書封面

圖書標簽Tags

無

評論、評分、閱讀與下載

---

    更鋒利的C#代碼 PDF格式下載

---