《Effective C#》Item 8：确保“0”在值类型中是有效的
大家在看了这标题后，肯定会觉的，为什么要确保“0”是有效的，这一点主要是跟值类型的内存分配有关，值类型有默认的构造函数，这是没法避免的，因此值类型变量中的成员在初始化的时候所出现的细微问题（对于值类型这方面的知识可以参看我前面一篇文章）。
http://blog.csdn.net/Knight94/archive/2006/07/01/861383.aspx
日常中比较常见的两种值类型，一个是enum定义的枚举类型，一个是用struct定义的数据类型。那我接下来就分别说明这两种类型如果不定义“0”为一个有效值的所能造成的后果，再分别说明如何加以修改来弥补这类错误。
对于enum定义的枚举类型来说，默认的起始值为0，但是如果在定义的时候，按照如下的方式去定义的话，有时候会造成意想不到的错误。
public enum ERROR_CODE
{
INVALID_FILE_NAME = 1001,
CANT_BE_ACCESS = 1002,
}
如上的定义是没有默认值0的，那么当我显示的去定义一个此类型变量，例如：
ERROR_CODE myError = new ERROR_CODE();
Debug.WriteLine( string.Format( "{0}", (int)myError ) );
可以看出如上的输出结果是0，但是它不是一个有效的值，也许这种错误可能很少出现，但是在struct复合类型中这种错误表现得更为明显。例如：
public struct ErrorMsg
{
private ERROR_CODE err;
private string strMsg;
// other properties or methods here
}
对于如上的结构类型来说，由于默认构造函数存在，所以当创建一个ErrorMsg变量的时候，那么对于err这个成员的值是无效的。有人可能会说，增加构造函数来限制等等的做法来避免这类错误。那么为什么与其在ErrorMsg中增加限制，不如在定义ERROR_CODE的时候就避免呢。其实这类错误的避免方法很简单，只要在ERROR_CODE中增加0的有效定义即可，例如比较正确形式的应该如下：
public enum ERROR_CODE
{
NO_ERROR = 0,
INVALID_FILE_NAME = 1001,
CANT_BE_ACCESS = 1002,
}
按照如上的做法就可以避免定义ERROR_CODE变量或者被组合到别的类型中的时候，都不会发生初始值是无效的尴尬局面。
在这本书中，对于枚举类型还提到一点，就是增加Flags标记的时候，一定要以None作为0，例如：
[Flags]
public enum Style
{
None = 0,
Flat = 1,
}
这样的目的是为了在与和或操作的时候能有意义。这方面的例子我就不多说了，例如：某个connection的状态，或者文件的某种属性等等都会用到类似的做法。
除了枚举类型外，对于struct定义的值类型来说，如果struct类型所包含的成员类型都是值类型的话，是没有什么问题（如果是自定义枚举类型，要参照上面所说的方法进行处理）；但是如果包含引用类型，则需要进行初始化，避免在访问的时候出现异常。例如对于前面所说的ErrorMsg来说，由于struct默认构造函数的存在，有可能在ErrorMsg类型变量在构造后，其的strMsg成员不是有效的。除了string类型外，常见的还有数组类型。如何避免类似的问题呢，方法是采用属性来实现。例如：
public struct ErrorMsg
{
private ERROR_CODE err;
private string strMsg;
public string Message
{
get
{
if( strMsg == null ) return string.Empty;
else
return strMsg;
}
}
// other properties or methods here
}
public struct IntArray
{
private int[] nArray;
public int[] Array
{
get
{
if( nArray == null )
nArray = new int[10];
return nArray;
}
}
}
所以在论坛上经常看到有人提出不能在struct中定义一个固定维数的数组，那么参照如上的方法，这类问题就能得到很好地解决。
最后再提一句，对于要确保“0”在所定义的值类型中是有效的这一点来说别小看。屏蔽错误从细微做起，而且好的编码习惯会使后面的工作事半功倍。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Knight94/archive/2006/08/09/1040766.aspx
