窗体命名规则与变量命名规则浅谈

比较流行的有两种命名约定：Pascal和Camel命名约定

     目前编程的命名方式主要有Pascal和Camel两种（Pascal：每个单词的首字母大写，例如ProductType；Camel：首个单词的首字母小写，其余单词的首字母大写，例如productType）

以下是一些常用的C#成员及其推荐命名方法： 

标志符	规则	实例与描述
类class	Pascal	Application
枚举类型enum	Pascal	记住，是以Pascal命名，切勿包含Enum，否则FXCop会抛出Issue
委托delegate	Pascal	以Pascal命名，不以任何特殊字符串区别于类名、函数名
常量const	全部大写	全部大写，单词间以下划线隔开
接口interface	Pascal	IDisposable 注：总是以 I 前缀开始，后接Pascal命名
方法function	Pascal	ToString
命名空间namespace	Pascal	以.分隔，当每一个限定词均为Pascal命名方式，比如： using ExcelQuicker.Framework
参数	Camel	首字母小写
局部变量	Camel	也可以加入类型标识符，比如对于System.String类型，声明变量是以str开头，string strSQL = string.Empty;
数据成员	Camel	以m开头＋Pascal命名规则，如mProductType（m意味member）
属性	Pascal

 

这个约定只是为了让我们的程序读起来更容易，但是如果按照约定来使你觉得很不舒服，那建议你还是别用，但你一定要有个自己的命名习惯，不要轻易的相信的你记忆能力，当你有一天突然想看你一个月前的代码的时候，你会发现你的规则是你唯一的依据了。

    按照这个约定，我们可以对我们的蔬菜价格变量进行一下命名，这里我只举几个简单的例子，为的是将理论应用于实践，具体的还要大家自己练习。我的英语只过四级，所以我喜欢用拼音来代替英语，但这绝对是一个毛病，英语水平高一些对于一个编程人员来说是至关重要的，因为毕竟这东西是人家美国人发明的，要是这东西是中国人发明的，我早成比尔·盖茨了。

    这里用到最多的应该是变量的命名了，以我们即将实现的第一个功能来说，我们将对蔬菜价格进行读取，鉴于水平的原因，我用了数组对采集的数据进行了存储，之后在数据库中进行了转存，这里就用到了数组的命名比如说我们的原始文件中存放着数据的格式是

 

01,2.02,2.04,2.08,0.00,0.03,2.50,2.90

 

02,2.00,2.04,2.08,0.00,0.03,2.50,2.90

 

03,2.99,2.04,2.08,0.00,0.03,2.50,2.90

 

04,2.87,2.04,2.08,0.00,0.03,2.50,2.90

 

05,2.65,2.04,2.08,0.00,0.03,2.50,2.90

 

06,2.45,2.04,2.08,0.00,0.03,2.50,2.90

......

 

分别表示

市场号，西红柿价格，黄瓜价格，芹菜价格，。。。。

要对各种数量进行存储，就要设置多个数组，下午茶曾经教育我要学会用多维数组，呵呵，马上就学！

这里我建议大家用多维数组，还有如果你要是想实现动态数量的数组的话，建议用2005提供的Arayylist对象，它能够提供一个动态数组的结构。

 

在局部变量命名时，使用Camel命名规则，

比如：int jiage = 0;

double shuliang = 0;

…

比如市场号这个数组，命名为shiChangHao[];

    西红柿命名为，xiHongShi[];.....

 

对于string类型定义字符串的时候，通常使用str前缀＋Pascal命名的方式，

比如string strSql = ""; //这是一种典型的命名SQL语句字符串的方式。

而对于此外的类型对象定义，通常的做法是使用obj前缀＋Pascal命名的方式，来告知我们这个变量是一个对象。或者也可以直接使用类名的Camel命名规则。

比如：Application objApplication = new Application();
            Application application = new Application();

 

 

数据成员命名以Camel命名方式，而属性以Pascal命名。通常如果数据成员与属性成对的话，数据成员与属性的命名区别仅在于变量名的第一个字母是小写还是大写。

比如

class Appcalition

{

        private ArrayList worksheetCollection = new ArrayList();

        public ArrayList WorksheetCollection

        {

            get

            {

                return this.worksheetCollection;

            }

        }

}

另外，类的成员数据/方法调用时，应该加上this限定符，this在编辑环境中是蓝色的，更利于我们区分局部变量、参数或静态变量，并且利于FXCop检测区分。（如果使用FxCop扫描和检测代码的话）

 

对于常量的命名，全部大写，单词间并且以下划线间隔，如public const int TIANSHU = 30;  虽然在MSDN中常量的命名推荐使用Pascal，但是从C++沿袭的命名规则来看，将常量全部大写更加能清楚的表示常量与普通变量之间的区别。

提醒大家一句的是尽量应用常量来表示常用数字，以免后期无法识别。

比如：

if(count<=30)

{}

......

//这样的编写是不利于阅读的

应写成

public const int TIANSHU= 30;

if(count<=TIANSHU)

{}

......

 

 

 

 

在一般情况下，不推荐缩写命名，不要担心变量命名长，长的变量名能使变量的意义更加清晰，其实从长变量名的负面作用三，因为Ctrl+C和Ctrl+V加上在VS中的智能感知，其负面追用已经很小。变量命名的原则是，尽最大努力让其他人在看到我们的变量/函数/…等的第一时间，大概能猜出它是做什么的。

比如：int productTypeCount = 0; //我们在第一时间就能知道它是记录产品的数量的变量

而对于糟糕的命名方式：int prodTypeCount = 0; //它是productTypeCount的简写，我们一部分人也许知道prod是product的缩写，但是每人能保证所有的人都知道它。我个人认为：最优秀的代码它本身就是注释。作为一流的程序员。并不仅仅实现功能，而是要让我们的代码更加优美，具备让他人维护或今后扩充的能力。作为现在的业务系统，其门槛的准入水平已大大降低，实现功能上的需求已没有什么难度，但是高手和菜鸟的区别在于，高手的代码通俗易懂，在整个编码的过程中，不仅能考虑到性能、还会考虑代码可读性和维护性。

数据库的字段、表名的命名都推荐采用Pascal命名方式，尽量不采用缩写。当然，使用长的字段名、表名，可能会使SQL语句的编写带来负面影响。我推荐大家可以使用一些ORM，ORM的性能肯定不会比直接写SQL的好，但是如果做业务系统，更重要的是系统多久能交付用户使用，ORM不仅使开发时间可以缩短不少，并且在后期的维护上也比直接写SQL便利很多。

注释方面，在代码文件的头部进行注释，这样做的好处在于，我们能对代码文件做变更跟踪。在代码头部分标注出创始人、创始时间、修改人、修改时间、代码的功能，这在团队开发中必不可少，它们可以使后来维护/修改的同伴在遇到问题时，在第一时间知道他应该向谁去寻求帮助，并且知道这个文件经历了多少次迭代、经历了多少个程序员的开发和修改。

样本：

?/P>

 

各个函数、属性、类

使用///三斜线注释，这种注释是基于XML的，不仅能导出XML制作帮助文档，而且在各个函数、属性、类等的使用中，编辑环境会自动带出注释，方便你的开发。以protected，protected Internal，public声明的定义注释都建议以这样命名方法。

例如：

/// <summary>

/// 用于从ERP系统中捞出产品信息的类

/// </summary>

class ProductTypeCollector

{

       …

}

界面控件命名

我的建议是使用默认控件名作为前缀，前缀名称全部小写，这样的好处是不必为未知的控件统一命名方式发愁，比如对于Label标签控件，有的人用缩写lbl，有的人用lab，有的人用lb。这样其实仍然是避免使用缩写，有的时候仍然会使命名变得冗长，但是命名更加能反应出变量的意义，并且各个开发人员也能更好的执行，因为他们不需要去背记各个变量的缩写。

protected System.Web.UI.WebControls.Button buttonQuery;

protected System.Web.UI.WebControls.DropDownList dropdownlistProductType;

protected System.Web.UI.WebControls.TextBox textboxManufactureDate;

 

5、代码可读性一些建议

（1）注意运算符的优先级，我们应该尽量使用括号明确表达式的操作顺序，避免使用默认优先级，给我们以及维护人带来困扰

（2）避免使用不易理解的数字，用有意义的标识来替代（枚举和常量）

比如：

if(productType == 0)        … else if (productType == 1)        … （不推荐使用）

if(productType == ProductType.CD)        … else if (productType == ProductType.DVD)        … （推荐使用）

 

（3）在界面层中尽量使用异常处理try语句，不要将系统级别的错误直接暴露给用户，而更应该的是把系统抛出的错误信息记录到LOG日志文件中去，告诉用户友好的提示信息

在Visual Studio 2005里面，有代码布局格式化功能，蛮有用的。其实代码的规范是为了使系统具有整体一致的编码风格，以使后期维护人员能更快的读懂代码并进行维护。我认为代码规范有其必要性，但不能因为规范而规范，从开发而言，开发是为了更快的做出稳定的系统，而稳定的系统是为了给公司带来受益。开发人员、项目管理人员都应该更多的从项目经营的角度出来，同时站在公司、客户的角度考虑问题，而不是因为代码而代码。