好程式碼、壞程式碼之二

4．多註釋，少廢話

程式碼，一定是給人看的，而程式碼本身的邏輯又決定於方法、型別和依賴的關係之中，所以，必要的註釋，是必需且必要的。透過註釋的進一步解釋，來輔助性地告知程式碼的邏輯、演算法或者流程，不僅是好習慣，更是好程式碼。

另一方面，註釋不是“無病呻吟”，沒有必要表述那些顯而易見的邏輯或者說明，同時注意區分單行註釋和多行註釋的應用。

在.NET平臺下，XML格式的註釋還肩負了另一項重要的使命，那就是根據註釋生成程式碼文件。例如：

///

/// 根據使用者資訊，構建標籤資訊

///

/// 使用者Id，根據使用者Id,獲取的例項資訊

/// 標籤資訊

/// 標籤資訊物件

public Tag BuildTag(int memberId, string tag)

{

return new Tag();

}

在Visual Studio中，可以透過選擇PropertiesàBuild來設定“XML documentation files”選項輸出生成XML資訊，例如上面的註釋資訊被生成為：

Anytao.Inside.Ch03.GoodCode

根據使用者資訊，構建標籤資訊

使用者Id，根據使用者Id,獲取 GoodCode.Member"/>的例項資訊

標籤資訊

標籤資訊物件

透過SandCastle工具就可以基於上述資訊生成標準統一的文件資訊，基於此方式就可以建立類似於MSDN文件的專案幫助檔案，大大簡化了這項“複雜”的工作。

5．用名稱空間組織你的程式碼

名稱空間，是邏輯上的組織單元，透過名稱空間建立對程式碼的有機組織，是現代語言的一大“創舉”，《Java夜未眠》作者蔡學鏞說：一個語言是否適合大型開發，可以從它對模組、名稱空間（或類似概念）支援的良窳看出端倪。從這個意義上說，名稱空間並不是大型開發或者團隊開發最重要的核心概念，但卻是加分的必要因素。

關於.NET名稱空間的詳細內容，請參考7.3節“using的多重身份”。

6．切勿模式而模式

設計模式是好的，而濫用模式是不好的。

瞭解和熟悉設計模式，是需要實踐和思考的過程，模式並不是一切問題的靈丹妙藥，而且大多時候的濫用反而造成更多的問題。濫用模式體現在兩個方面：

· 不慎誤用，在不合適的場合應用不合適的模式，例如不是所有的場合都需要引入工廠解耦物件建立；對於依賴於執行狀態的場合，並非只有狀態模式一種選擇，工作流或許能帶來更好的控制。

· 過度應用，模式的引入都會或多或少地介入了中間層或者中間程式碼，過度的模式應用將導致程式碼複雜度的直線上升，除了會帶來效能上的問題還有邏輯上的混亂。

舉一個簡單的例子，策略模式是將演算法從宿主類中剝離出來，將易於變化的部分封裝為介面，例如：

public interface ITax

{

decimal Calculate(decimal value);

}

public class FoodTax : ITax

{

public decimal Calculate(decimal value)

{

return new decimal(1 + 0.15) * value;

}

public class RetailTax : ITax

{

public decimal Calculate(decimal value)

{

return new decimal(1 + 0.1) * value;

}

對於演算法分離而言，透過ITax策略可以很好地進行不同行業（例如飲食FoodTax或者零售RetailTax）稅率的計算，不同的行業提供不同的演算法策略，然而對於變化的稅率而言，這種實現的方式略顯過度，越來越多的演算法策略將造成程式碼的過度膨脹。所以完全可以對策略的方式進行改良，利用委託將稅率演算法分離看起來更加簡潔而優雅：

public interface ITax

{

decimal Calculate(Func rateProvider, decimal value);

}

public class Tax : ITax

{

public decimal Calculate(Func rateProvider, decimal value)

{

var rate = rateProvider.Invoke();

return rate * value;

}

一下子清爽了很多，避免了“策略”帶來過度膨脹，又很好地解決了稅率演算法的變化與分離，對於客戶端的消費並沒有太大的差別。

《倚天屠龍記》中有一個重要的片段，張三丰指點張無忌修煉太極，有一段“此時無招勝有招”的精彩論述，武術上真正的無敵不在乎一招一式的死記硬背，也不在於一刀一劍的激情揮灑。同樣的道理，似乎更適合用於軟體設計與模式，很多時候，架構與設計的極致不在於對模式的“應用”，而在於對模式的“活用”，在於靈魂附體，在於無招勝有招。

本文節選自《你必須知道的.NET（第2版）》一書

圖書詳細資訊:http://space.itpub.net/13164110/viewspace-704514

好程式碼、壞程式碼之二