天天躁日日躁狠狠躁AV麻豆-天天躁人人躁人人躁狂躁-天天澡夜夜澡人人澡-天天影视香色欲综合网-国产成人女人在线视频观看-国产成人女人视频在线观看

關于代碼規范

  今天被培訓了C#代碼規范,為了統一風格。其中我比較有異議的兩點如下:

  1. 類型實例的私有字段應采用駱駝命名法(camelCasing),不應該有任何前綴,在使用時前邊加"this.”;
  2. 要用FCL類型而不是C#的基元類型,例如要使用Int32代替int。

  首先對于第一點,個人比較習慣的做法是前邊加下劃線,說不上好壞,這兩種寫法在各種開源框架的源碼中都見到過。由于VS默認并不提供像Eclipse那樣的對私有字段變色的功能,所以如果只是簡單的使用camelCasing的話會很難區分哪些是私有字段,哪些是局部變量,所以才有了加this的要求。那么來做個比較:

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";    }}

  哪個更能一眼看出其中的私有字段來?似乎并沒有明顯的區別,相反當局部使用的字段比較多的時候,加下劃線反而顯得更凌亂一點。

  但是,this不是單為field而設置的,實例的屬性,方法,事件都可以使用,一旦我們習慣了使用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 += () => { };}

  哪個更能一眼看出其中的私有字段來?這個例子可能偏激了一些,但足以表達我的意思。

  另一方面來說,一旦我敲下了this.,由于VS的智能提示,會出現一大堆的提示項讓我腦袋發蒙,但是當我敲一個下劃線之后,出現的就只會是所有的私有字段了,干凈了許多。

  m_的前綴也是一個不錯的選擇,而且這兩種前綴當我們使用快捷鍵生成屬性的時候,VS都會聰明地把前綴去掉,首字母大寫,只顯示我們想要的名字。

  好吧如果這一條規則我還能接受的話,第二個規則就實在讓我無法理解了。

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

  培訓人并沒有說清楚為什么要這么做,從《CLR via C#》這本書中看出,作者也是強烈建議使用FCL類型,他的理由大致是:有些人對int表示什么有困惑,認為在32位機器上就代表Int32,在64位機器上就代表Int64,如果我們直接使用Int32就不會有這樣的困擾;long在很多語言中不是64位的,這讓習慣于這些語言的人看C#會有誤解;等等。

  這些理由我都承認,但我認為不足以說服我使用FCL類型,我的理由如下:

  1. 我認識的同事,95%都使用C#的基元類型來敲代碼,如果一個規則要讓絕大多數人都更改自己的習慣,那么它本身就不合理,而且不可能實施得很順利。
  2. VS的智能提示都擅自主張地使用C#基元類型而不是FCL類型,即使你用FCL類型編寫了一個方法,在我們使用時出現在智能提示中的仍然是基元類型。如果我看到一個方法返回long型,我很自然地會使用一個long去接收它,如果前邊寫一個Int64接收一個返回long的方法不覺得別扭么?如果我是新手我是不是認為這還是個隱式轉型呢?
  3. 從習慣上來說,我敲一個int比敲一個Int32快許多,也舒服很多。我敲一個Int64更是痛苦無比,每次都要低頭去找6在哪。我按6最多的時候是玩魔獸的時候,但是玩魔獸和敲代碼食指的位置不一樣啊,我總是按到7啊。
  4. 我個人喜歡藍色,比那個藍不藍綠不綠的好看多了,這個純粹是吐槽。

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

NET技術關于代碼規范,轉載需保留來源!

鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播更多信息之目的,如作者信息標記有誤,請第一時間聯系我們修改或刪除,多謝。

主站蜘蛛池模板: 天天爽夜夜爽 | 在线观看99 | 最近最新中文字幕MV高清在线 | 24小时日本在线观看片免费 | 动漫成年美女黄漫网站 | 久久机热视频免费 | 亚洲国产高清视频在线观看 | 亚洲精品不卡在线 | 国产高清视频在线观看97 | 久久亚洲电影www电影网 | 国产精品国产三级国产an | 精品国产一区二区三区久久影院 | 果冻传媒 在线播放观看 | 偷窥美女3 | 亚洲成色WWW久久网站夜月 | ppypp午夜限制不卡影院私人 | avav去吧 | XXOO麻豆国产在线九九爱 | 狠狠综合久久综合88亚洲 | 动漫美女和男人下载 | 超碰97视频在线观看 | 亚洲国产在线视频中文字 | 国产精品高清视亚洲一区二区 | 日本精品久久无码影院 | 青柠在线电影高清免费观看 | 最新亚洲人成网站在线影院 | 十九岁在线观看免费完整版电影 | 日韩人妻无码精品久久中文字幕 | 上原结衣快播 | 国产在线高清视频无码 | 国产在线观看免费观看不卡 | 无套暴躁白丝秘书 | 国产香蕉视频在线观看 | 中文日产无乱码AV在线观 | 国产精品久久久久久久久免费下载 | 久久一er精这里有精品 | 不卡一区二区高清观看视频 | 狠狠色狠狠色综合日日32 | 脔到她哭H粗话HWWW男男动漫 | 国产在线视频一区二区不卡 | 69夫妻交友网 |