好代码、坏代码之二
好代码、坏代码之二
4．多注释，少废话
代码，一定是给人看的，而代码本身的逻辑又决定于方法、类型和依赖的关系之中，所以，必要的注释，是必需且必要的。通过注释的进一步解释，来辅助性地告知代码的逻辑、算法或者流程，不仅是好习惯，更是好代码。
另一方面，注释不是“无病呻吟”，没有必要表述那些显而易见的逻辑或者说明，同时注意区分单行注释和多行注释的应用。
在.NET平台下，XML格式的注释还肩负了另一项重要的使命，那就是根据注释生成代码文档。例如：
/// <summary>
/// 根据用户信息，构建标签信息
/// </summary>
/// <param name="memberId">用户Id，根据用户Id,获取<see cref="Member"/>的实例信息</param>
/// <param name="tag">标签信息</param>
/// <returns>标签信息对象</returns>
public Tag BuildTag(int memberId, string tag)
{
return new Tag();
}
在Visual Studio中，可以通过选择PropertiesàBuild来设置“XML
documentation files”选项输出生成XML信息，例如上面的注释信息被生成为：
<?xml version="1.0"?>
<doc>
<assembly>
<name>Anytao.Inside.Ch03.GoodCode</name>
</assembly>
<members>
<member name="M:Anytao.Inside.Ch03.GoodCode.Tag.BuildTag(System.Int32,System.String)">
<summary>
根据用户信息，构建标签信息
</summary>
<param name="memberId">用户Id，根据用户Id,获取<see cref="T:Anytao.Inside.Ch03. GoodCode.Member"/>的实例信息</param>
<param name="tag">标签信息</param>
<returns>标签信息对象</returns>
</member>
</members>
</doc>
通过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<decimal> rateProvider, decimal value);
}
public class Tax : ITax
{
public decimal Calculate(Func<decimal> rateProvider, decimal value)
{
var rate = rateProvider.Invoke();
return rate * value;
}
}
一下子清爽了很多，避免了“策略”带来过度膨胀，又很好地解决了税率算法的变化与分离，对于客户端的消费并没有太大的差别。
《倚天屠龙记》中有一个重要的片段，张三丰指点张无忌修炼太极，有一段“此时无招胜有招”的精彩论述，武术上真正的无敌不在乎一招一式的死记硬背，也不在于一刀一剑的激情挥洒。同样的道理，似乎更适合用于软件设计与模式，很多时候，架构与设计的极致不在于对模式的“应用”，而在于对模式的“活用”，在于灵魂附体，在于无招胜有招。
本文节选自《你必须知道的.NET（第2版）》一书
图书详细信息:http://www.cnblogs.com/broadview/archive/2011/08/09/2132689.html
