3.3 結構類型（Struct types）的默認值
對於結構類型（Struct types），其所包含的值類型字段會被初始化為對應的默認值，而引用類型字段會被初始化為null。
// Code #11
// See Code #02 for Alignment.
public struct MyStruct
{
public int Integer;
public Alignment Align;
public string Text;
}
那麼，如下代碼：
MyStruct m = new MyStruct();
Console.WriteLine(m.Integer);
Console.WriteLine(m.Align);
Console.WriteLine(m.Text == null);
運行結果將是：
0
Left
True
4.你認為如何使用枚舉才恰當？
現在，把本文之前的都忘了，認真地考慮一下這個問題：
你認為如何使用枚舉才恰當？
嗯，這是一個非常大的問題，要對其進行較全面的回答明顯超出我的能力范圍，如果勉強為之必定贻笑大方。但我不能置之不理，於是我只好把自己的想法作拋磚引玉之用。
太極的精髓不在其招式而在其理念，沒有思想的軀體猶如行屍走肉。語言的最基本作用是交流。要成功進行交流，你得先有想法，再運用語言規則把它表達出來，傳達給你的受眾，進而達到交流的目的。至於交流的效果，就要看你對語言規則的熟悉程度和運用功底了。
程序設計語言亦然，它不但是你跟計算機交流的橋梁，更是你跟下一個代碼維護者交流的橋梁。或許你的代碼是合法的，因為計算機能讀懂它，但這不代表你的代碼是友好的，因為下一個代碼維護者可能根本摸不著頭腦。易地而處，如果你將要維護某人龍飛鳳舞的作品，你可能早早就拍台踢凳了。我認為你絕對有責任為下一個代碼維護者著想一下。再者，下一個代碼維護者也可能是你自己，不知你有否嘗過隔了一段較長的時間後再回顧自己曾經的代碼時所感到的陌生感覺？
每一種語言都有著不為人所推薦的雷區和陷阱。由於某些原因，人們不能把這些雷區和陷阱徹底清除，為了眾人，人們把這些惱人的東西給隱藏起來，而你卻偏偏要把它挖出來看個究竟。在這灰色地帶的國度裡，對與錯的界限非常模糊，很多東西既不禁止也不推薦，於是沉默可能是最好的選擇。“沉默是因為包容”，然而，這卻被你拿來當作你那句“你說給過我縱容”的理由。細細品味周傑倫的《借口》，你或許也能從中體會到其中的無奈。
我們所處的世界極其復雜，以至於到目前還不能徹底摸清它的來頭，但我們從未放過任何一個探索的機會。零散散亂的知識對我們更好的認識這個世界基本不起什麼作用，我們需要的是結構化、系統化的知識體系，以便協助我們更全面的俯瞰這個世界的微妙。合理建立分類使得我們能夠更好的整理現有的知識，每一種分類方式又從某個側面把相關的知識聯系並展現出來，使得我們能夠更加有效的運用這些相關聯的知識。
我覺得一個枚舉類型就是一種分類方法。它使得你能夠從某一側面透視你的目標群體。對於一段給定的文字（string Class），我們既可以從文字樣式（FontStyle Enumeration）的角度來看待它，也可以從對齊類型（Alignment Enumeration）的角度去分析它，還可以從顏色（KnownColor Enumeration）的角度去考察它。我們的行動應該是本著一定的目的的，如果你壓根就不知道為何要這樣做，那麼不這樣做可能是最合適的。
回顧本文上面所說的一切，你認為我們真的有必要用new來初始化枚舉變量嗎？如果枚舉代表一種分類的思想，那麼為什麼你還要冒險令枚舉變量（有可能）儲存非預定義枚舉（成員）值呢（見3.2.2節）？
