筆者今天被培訓(xùn)了C#代碼規(guī)范，為了統(tǒng)一風(fēng)格。其中我比較有異議的兩點(diǎn)如下：

1.類型實(shí)例的私有字段應(yīng)采用駱駝命名法（camelCasing），不應(yīng)該有任何前綴，在使用時(shí)前邊加"this.”；

2.要用FCL類型而不是C#的基元類型，例如要使用Int32代替int。

首先對(duì)于第一點(diǎn)，個(gè)人比較習(xí)慣的做法是前邊加下劃線，說(shuō)不上好壞，這兩種寫法在各種開(kāi)源框架的源碼中都見(jiàn)到過(guò)。由于VS默認(rèn)并不提供像Eclipse那樣的對(duì)私有字段變色的功能，所以如果只是簡(jiǎn)單的使用camelCasing的話會(huì)很難區(qū)分哪些是私有字段，哪些是局部變量，所以才有了加this的要求。那么來(lái)做個(gè)比較：

public void Test()  
{  
    _age = DateTime.Now.Year - _birth.Year;  
    if (_birth > new DateTime(2000, 1, 1))  
    {  
        _name += " new century";  
    }  
}  
 
public void Test2()  
{  
    this.age = DateTime.Now.Year - this.birth.Year;  
    if (this.birth > new DateTime(2000, 1, 1))  
    {  
        this.name += " new century";  
    }  
} 

哪個(gè)更能一眼看出其中的私有字段來(lái)？似乎并沒(méi)有明顯的區(qū)別，相反當(dāng)局部使用的字段比較多的時(shí)候，加下劃線反而顯得更凌亂一點(diǎn)。

但是，this不是單為field而設(shè)置的，實(shí)例的屬性，方法，事件都可以使用，一旦我們習(xí)慣了使用this：

public void Test()  
{  
    Prop1++;  
    _age = DateTime.Now.Year - _birth.Year;  
    Method1();  
    if (_birth > new DateTime(2000, 1, 1))  
    {  
        Prop2 += " abcd";  
        _name += " new century";  
    }  
    Event1 += () => { };  
}  
 
public void Test2()  
{  
    this.Prop1++;  
    this.age = DateTime.Now.Year - this.birth.Year;  
    this.Method1();  
    if (this.birth > new DateTime(2000, 1, 1))  
    {  
        this.Prop2 += " abcd";  
        this.name += " new century";  
    }  
    this.Event1 += () => { };  
} 

哪個(gè)更能一眼看出其中的私有字段來(lái)？這個(gè)例子可能偏激了一些，但足以表達(dá)我的意思。

另一方面來(lái)說(shuō)，一旦我敲下了this.，由于VS的智能提示，會(huì)出現(xiàn)一大堆的提示項(xiàng)讓我腦袋發(fā)蒙，但是當(dāng)我敲一個(gè)下劃線之后，出現(xiàn)的就只會(huì)是所有的私有字段了，干凈了許多。

m_的前綴也是一個(gè)不錯(cuò)的選擇，而且這兩種前綴當(dāng)我們使用快捷鍵生成屬性的時(shí)候，VS都會(huì)聰明地把前綴去掉，首字母大寫，只顯示我們想要的名字。

好吧如果這一條規(guī)則我還能接受的話，第二個(gè)規(guī)則就實(shí)在讓我無(wú)法理解了。

要用FCL類型而不是C#的基元類型，例如要使用Int32代替int。

培訓(xùn)人并沒(méi)有說(shuō)清楚為什么要這么做，從《CLR via C#》這本書中看出，作者也是強(qiáng)烈建議使用FCL類型，他的理由大致是：有些人對(duì)int表示什么有困惑，認(rèn)為在32位機(jī)器上就代表Int32，在64位機(jī)器上就代表Int64，如果我們直接使用Int32就不會(huì)有這樣的困擾；long在很多語(yǔ)言中不是64位的，這讓習(xí)慣于這些語(yǔ)言的人看C#會(huì)有誤解；等等。

這些理由我都承認(rèn)，但我認(rèn)為不足以說(shuō)服我使用FCL類型，我的理由如下：

1.我認(rèn)識(shí)的同事，95%都使用C#的基元類型來(lái)敲代碼，如果一個(gè)規(guī)則要讓絕大多數(shù)人都更改自己的習(xí)慣，那么它本身就不合理，而且不可能實(shí)施得很順利。

2.VS的智能提示都擅自主張地使用C#基元類型而不是FCL類型，即使你用FCL類型編寫了一個(gè)方法，在我們使用時(shí)出現(xiàn)在智能提示中的仍然是基元類型。如果我看到一個(gè)方法返回long型，我很自然地會(huì)使用一個(gè)long去接收它，如果前邊寫一個(gè)Int64接收一個(gè)返回long的方法不覺(jué)得別扭么？如果我是新手我是不是認(rèn)為這還是個(gè)隱式轉(zhuǎn)型呢？

3.從習(xí)慣上來(lái)說(shuō)，我敲一個(gè)int比敲一個(gè)Int32快許多，也舒服很多。我敲一個(gè)Int64更是痛苦無(wú)比，每次都要低頭去找6在哪。我按6最多的時(shí)候是玩魔獸的時(shí)候，但是玩魔獸和敲代碼食指的位置不一樣啊，我總是按到7啊。

4.我個(gè)人喜歡藍(lán)色，比那個(gè)藍(lán)不藍(lán)綠不綠的好看多了，這個(gè)純粹是吐槽。

對(duì)于統(tǒng)一編碼規(guī)范我是舉雙手贊同的，尤其在交接工作比較頻繁的時(shí)候，看著各種各樣新奇的命名法總是讓人心里抓狂。程序員都多多少少有一些潔癖吧，看到不符合自己風(fēng)格的就想去改。我不是做決定的人，但我總是希望一個(gè)人在替很多人做決定時(shí)還是廣泛征求下意見(jiàn)比較好，不要輕易地把自己的習(xí)慣強(qiáng)加給別人，除非你有充足的理由說(shuō)服我。對(duì)于一個(gè)熱愛(ài)這項(xiàng)職業(yè)的程序員來(lái)說(shuō)，能舒舒服服地敲代碼是一種幸福，但是服從上級(jí)的安排，為大局著想又是我的義務(wù)，要是能舒舒服服地完成義務(wù)該多好。

原文鏈接：http://www.cnblogs.com/Tyr-Tian/archive/2011/04/28/2032233.html