C# 编程/命名
本节将定义 C# 开发社区普遍接受的命名约定。一些公司可能会定义与之不同的命名约定,但这在个别情况下进行,通常不鼓励。本节中讨论的一些对象可能超出了读者目前的知识范围,但可以以后再参考本节。
许多命名标准源自微软的 .NET 框架库。这些标准已被证明可以使名称易于阅读和理解。“一目了然”。通过在命名对象时使用正确的约定,您可以确保其他阅读您代码的 C# 程序员能够轻松理解这些对象,而无需搜索代码以查找其定义。
命名空间使用帕斯卡命名法(也称为UpperCamelCase
)命名,不带下划线。这意味着名称中每个单词的第一个字母都大写。例如:MyNewNamespace
。帕斯卡命名法还意味着三个或更多个字母的缩略词只应首字母大写(MyXmlNamespace 而不是 MyXMLNamespace)。
如果程序集只包含一个命名空间,则程序集和命名空间应使用相同的名称。否则,程序集应遵循正常的帕斯卡命名法格式。
帕斯卡命名法,不带下划线或前导C
,cls
,或I
。类不应与它们所在的命名空间同名。任何三个或更多个字母的缩略词都应使用帕斯卡命名法,而不是全部大写。尽量避免缩写,并尽量始终使用名词。
遵循类命名约定,但在名称末尾添加 Exception。在 .Net 2.0 中,所有类都应从System.Exception
基类继承,而不是从System.ApplicationException
继承。
遵循类命名约定,但以I
开头,并将I
之后的字母大写。例如:IFoo
。I
前缀有助于区分接口和类,并避免名称冲突。
帕斯卡命名法,不带下划线,事件处理程序除外。尽量避免缩写。许多程序员有过度缩写一切的坏习惯。应该避免这种情况。
帕斯卡命名法,不带下划线。尽量避免缩写。
骆驼命名法(或lowerCamelCase
)。尽量避免缩写。骆驼命名法与帕斯卡命名法相同,但第一个单词的第一个字母小写。
骆驼命名法,以下划线开头。始终在声明中表明protected
或private
。以下划线开头是本文档中唯一有争议的地方。前导字符有助于防止在构造函数中发生名称冲突(参数和私有变量具有相同的名称)。
帕斯卡命名法,以标识它属于 UI 而不是纯粹的编码控件(例如一个临时变量)的前缀。许多开发人员使用ui
作为前缀,后跟描述性名称,例如txtUserName
或lblUserNickName
(“txt”代表 TextBox 控件,“lbl”代表 Label 控件)
这实际上是骆驼命名法;此外,这种命名约定被称为匈牙利命名约定,在现代编程中通常不鼓励。这种风格的变量具有类似 lblSurname 或 tbSurname 的名称,而不是 surnameLabel 或 surnameTextBox。这也有额外的好处,即类似的 UI 元素在 IntelliSense 中按字母顺序连续排列。
下面是一些针对 ASP.Net 网页表单控件的示例
控件 | 前缀 | 示例 |
---|---|---|
标签 | lbl | lblSurname |
文本框(ASP.Net) | tb | tbSurname |
文本框(WinForms) | txt | txtUserName |
数据网格 | dg | dgResults |
网格视图 | gv | gvResults2 |
按钮 | btn | btnSave |
图像按钮 | iBtn | iBtnSave |
超链接 | lnk | lnkHomePage |
组合框 | cmb | cmbYear |
下拉列表 | ddl | ddlCompany |
列表框 | lst | lstCompany |
数据列表 | dLst | dLstAddress |
数据集 | ds | dsInvoices |
数据表 | dt | dtClients |
数据行 | dr | drUser |
中继器 | rep | repSection |
复选框 | chk | chkMailList |
复选框列表 | chk | chkAddress |
单选按钮 | rBtn | rBtnGender |
单选按钮列表 | rBtn | rBtnAgeGroup |
图像 | img | imgLogo |
面板 | pnl | pnlSevtion |
PlaceHolder | plh | plhHeader |
日历 | cal | calMyDate |
广告轮播器 | adr | adrBanner |
表格 | tbl | tblResults |
所有验证器 | val (N/A) | valCreditCardNumber |
验证摘要 | vals (N/A) | valsErrors |
帕斯卡命名法。不建议使用 SCREAMING_CAPS。这与早期的约定有很大不同。大多数开发人员现在意识到,使用 SCREAMING_CAPS 会暴露比必要更多的实现细节。大部分的 .NET Framework 设计指南 都专门讨论了这个问题。
以下是一个使用所有这些命名约定的类的示例。
using System;
namespace MyExampleNamespace
{
public class Customer : IDisposable
{
private string _customerName;
public string CustomerName
{
get
{
return _customerName;
}
set
{
_customerName = value;
_lastUpdated = DateTime.Now;
}
}
private DateTime _lastUpdated;
public DateTime LastUpdated
{
get
{
return _lastUpdated;
}
private set
{
_lastUpdated = value;
}
}
public void UpdateCustomer(string newName)
{
if (!newName.Equals(CustomerName))
{
CustomerName = newName;
}
}
public void Dispose()
{
//Do nothing
}
}
}