今天被培训了C#代码规范，为了统一风格。其中我比较有异议的两点如下：
- 类型实例的私有字段应采用骆驼命名法（camelCasing），不应该有任何前缀，在使用时前边加"this.”；
- 要用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类型，我的理由如下：
- 我认识的同上海闵行企业网站设计与制作事，95%都使用C#的基元类型来敲代码，如果一个规则要让绝大多数人都更改自己的习惯，那么它本身就不合理，而且不可能实施得很顺利。
- VS的智能提示都擅自主张地使用C#基元类型而不是FCL类型，即使你用FCL类型编写了一个方法，在我们使用时出现在智能提示中的仍然是基元类型。如果我看到一个方法返回long型，我很自然地会使用一个lo上海徐汇企业网站制作ng去接收它，如果前边写一个Int64接收一个返回long的方法不觉得别扭么？如果我是新手我是不是认为这还是个隐式转型呢？
- 从习惯上来说，我敲一个int比敲一个Int32快许多，也舒服很多。我敲一个Int64更是痛苦无比，每次都要低头去找6在哪。我按6最多的时候是玩魔兽的时候，但是玩魔兽和敲代码食指的位置不一样啊，我总是按到7啊。
- 我个人喜欢蓝色，比那个蓝不蓝绿不绿的好看多了，这个纯粹是吐槽。
对于统一编码规范我是举双手赞同的，尤其在交接工作比较频繁的时候，看着各种各样新奇的命名法总是让人心里抓狂。程序员都多多少少有一些洁癖吧，看到不符合自己风格的就想去改。我不是做决定的人，但我总是希望一个人在替很多人做决定时还是广泛征求下意见比较好，不要轻易地把自己的习惯强加给别人，除非你有充足的理由说服我。对于一个热爱这项职业的程序员来说，能舒舒服服地敲代码是一种幸福，但是服从上级的安排，为大局着想又是我的义务，要是能舒舒服服地完成义务该多好。
