更鋒利的C#代碼

前言

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

內(nèi)容概要

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

作者簡介

　　包善東（網(wǎng)名Richard Bao），群碩軟件開發(fā)有限公司的一名交互設(shè)計師和軟件工程師。9歲時萌生了對編程的濃厚興趣，從此走上了軟件開發(fā)的道路，至今已積累了十多年的編程經(jīng)驗。作者還曾是其學(xué)校交響樂團的大提琴兼鋼琴演奏員，在英、法、德、港、臺及內(nèi)地多次進行演出。也許是音樂與藝術(shù)思想對編程的滲透，使其在編程中往往善于尋找和諧之美，避免一切生搬硬套。這也許才是《更鋒利的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 嵌套或包含關(guān)系引起的縮進1.3.2 因換行而產(chǎn)生的縮進1.3.3 使用空格還是Tab鍵1.4 大括號1.4.1 大括號的位置1.4.2 空的大括號結(jié)構(gòu)1.4.3 僅包含單個語句的結(jié)構(gòu)體1.5 保持項目文件的條理性1.5.1 解決方案的結(jié)構(gòu)呼應(yīng)1.5.2 代碼文件的結(jié)構(gòu)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 結(jié)構(gòu)與類的XML文檔注釋2.3.2 屬性的XML文檔注釋2.3.3 方法的XML文檔注釋2.3.4 構(gòu)造函數(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 應(yīng)在何時使用何種大小寫規(guī)則3.3 考慮跨語言編程3.3.1 不要通過大小寫區(qū)分標識符3.3.2 避免與其他語言的關(guān)鍵字重復(fù)3.3.3 避免使用特定語言的術(shù)語3.4 命名一致與沖突3.4.1 大小寫無關(guān)原則3.4.2 對基類型的命名暗示3.4.3 對參數(shù)與屬性的關(guān)系暗示3.4.4 屬性名稱與自身類型同名3.4.5 與命名空間相關(guān)的命名沖突3.5 匈牙利命名法3.5.1 匈牙利命名法的弊端3.5.2 考慮為控件應(yīng)用匈牙利命名法第4章處理數(shù)據(jù)4.1 關(guān)于數(shù)據(jù)類型4.1.1 整數(shù)4.1.2 浮點數(shù)4.1.3 布爾類型4.1.4 字符與字符串4.2 變量的使用4.2.1 盡可能使用內(nèi)置關(guān)鍵字4.2.2初始化一切變量4.2.3 集中使用變量4.3 使用枚舉4.3.1 何時使用枚舉4.3.2 如何為枚舉命名4.3.3 關(guān)于枚舉項4.3.4 標記枚舉4.4 魔數(shù)——以字面數(shù)值出現(xiàn)在代碼中的常量4.5 復(fù)雜的表達式4.5.1 運算符的副作用4.5.2簡化表達式第5章分支結(jié)構(gòu)5.1 使用if結(jié)構(gòu)5.1.1“==”與“=”的問題5.1.2 如何處理復(fù)雜的條件5.2 使用switch結(jié)構(gòu)5.2.1 break語句5.2.2 使用default子句要注意的問題5.3 選擇if還是switch5.4 關(guān)于判斷順序的設(shè)計5.4.1 先判斷最有可能成立的條件5.4.2 預(yù)防因條件短路而丟失操作5.5 慎用goto語句第6章 循環(huán)結(jié)構(gòu)6.1 使用for還是while6.1.1 for和while的語義比較6.1.2 簡單的數(shù)值迭代——for和while的思維模式的差j6.1.3 預(yù)知循環(huán)次數(shù)——微波爐加熱的啟示6.1.4 集合迭代——獨特的foreach結(jié)構(gòu)6.2 循環(huán)變量的使用6.2.1 循環(huán)變量的命名6.2.2 循環(huán)變量的定義6.2.3 避免循環(huán)變量的非常規(guī)應(yīng)用6.3 提高循環(huán)效率6.3.1 避免不必要的重復(fù)勞動6.3.2 避免不必要的循環(huán)第7章 如何使用函數(shù)7.1 為什么要使用函數(shù)7.1.1 函數(shù)與方法7.1.2 代碼復(fù)用7.1.3 隱藏細節(jié)——使用函數(shù)進行抽象7.2 函數(shù)重載7.2.1 重載的語義——為調(diào)用者提供方便7.2.2 保持核心代碼唯一7.3 參數(shù)的設(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章 結(jié)構(gòu)與類8.1 結(jié)構(gòu)與類的比較8.1.1 值類型與引用類型8.1.2 何時應(yīng)當使用結(jié)構(gòu)8.1.3 何時應(yīng)當使用類8.2 結(jié)構(gòu)與類的命名8.2.1 措辭8.2.2 避免與命名空間沖突8.2.3 不要使用“C”前綴8.2.4后綴的使用8.3 如何搭建一個典型的結(jié)構(gòu)8.3.1 找準核心數(shù)據(jù)8.3.2 數(shù)據(jù)的表現(xiàn)形式8.3.3 定義等價原則8.3.4實現(xiàn)基本運算8.4 如何真正面向?qū)ο蟮?章 封裝9.1 構(gòu)造函數(shù)9.1.1 構(gòu)造函數(shù)的語義9.1.2 何時使用靜態(tài)構(gòu)造方法9.1.3 構(gòu)造函數(shù)的參數(shù)及其初始化9.2 Finalize函數(shù)9.2.1 垃圾回收器9.2.2 IDisposable接口——顯式釋放資源的方法9.2.3 釋放資源的一般范式9.3 何時應(yīng)該使用字段9.3.1 存儲核心數(shù)據(jù)9.3.2 維持中間結(jié)果9.3.3 常量字段9.4 如何使用字段9.4.1 字段的命名9.4.2 訪問控制9.5 何時應(yīng)該使用屬性9.5.1 屬性的語義9.5.2 數(shù)據(jù)訪問控制9.5.3 需要的后續(xù)操作9.5.4 簡單的數(shù)據(jù)處理9.5.5 預(yù)定義的對象實例9.6 如何使用屬性9.6.1 屬性的命名9.6.2 訪問控制9.6.3 提供合理的默認值9.6.4 保持輕量級的操作9.6.5 在屬性中拋出異常9.7 何時應(yīng)該使用方法9.7.1 表示某種操作9.7.2 耗時的任務(wù)——方法在形式上的暗示作用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 關(guān)于接口10.3.1 接口的語義10.3.2 接口的命名10.3.3 使用接口還是類繼承10.4 何時應(yīng)當顯式實現(xiàn)接口10.4.1 解決接口之間的命名沖突10.4.2 提供強類型操作10.4.3 隱藏僅用于通過接口訪問的成員10.5 使用多態(tài)10.5.1 何時應(yīng)進行重寫10.5.2 應(yīng)當重寫哪個成員10.5.3 保持參數(shù)名稱一致10.6運算符重載10.6.1 可重載的運算符10.6.2 符合運算符的本意10.6.3 運算符的關(guān)聯(lián)性10.6.4 類型轉(zhuǎn)換運算符的重載第11章 泛型機制11.1 裝箱與取消裝箱11.2 何時使用泛型11.3 泛型的類型參數(shù)設(shè)計11.3.1 類型參數(shù)的命名11.3.2 使用類型參數(shù)的時機第12章 事件與委托12.1 何為事件驅(qū)動模式12.2 如何響應(yīng)事件12.2.1 事件處理函數(shù)12.2.2代碼的分配12.2.3 事件偵聽器的使用12.3如何提供事件12.3.1 何時應(yīng)當提供事件12.3.2 事件的命名12.3.3 傳遞與事件相關(guān)的數(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)內(nèi)置集合類型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 元素結(jié)構(gòu)13.2.5 排序13.3 性能比較13.4 提供自己的集合類型13.4.1 何時應(yīng)提供集合類型13.4.2 集合類型的命名13.4.3 提供與內(nèi)置集合類型一致的行為13.4.4 索引器及其應(yīng)遵守的規(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查詢的相關(guān)機制14.3.1 匿名類型14.3.2 隱式類型的局部變量14.3.3 Lambda表達式與匿名函數(shù)第15章 異常15.1 處理異常時應(yīng)遵守的規(guī)范15.2 拋出異常15.2.1 異常的語義15.2.2 不應(yīng)使用異常的位置15.2.3 控制異常15.2.4 異常的重新拋出——重新包裝時要注意的15.3 選用合適的異常類型15.3.1 常見的異常類型15.3.2 不應(yīng)使用的異常類型15.4 異常提示信息15.5 設(shè)計自定義異常及應(yīng)遵循的約定第16章 全球化與本地化16.1 分離與特定區(qū)域相關(guān)的信息16.2 處理特定區(qū)域性的數(shù)據(jù)16.2.1 區(qū)分區(qū)域性與界面區(qū)域性16.2.2 在內(nèi)部使用Unicode16.2.3 文本的比較與排序16.2.4 不要假定區(qū)域性的行為16.3 何時使用固定區(qū)域性16.4 用戶界面應(yīng)注意的細節(jié)16.4.1 使用資源16.4.2 術(shù)語16.4.3 界面布局16.4.4 歧義16.4.5 組合文本附錄A：C#、VB.NET、J#關(guān)鍵字表附錄B：常用的異常類型

章節(jié)摘錄

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

編輯推薦

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

圖書封面

圖書標簽Tags

無

評論、評分、閱讀與下載

---

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

---