ASP.NET 控件的命名准则是什么？答案

【问题标题】：What are the naming guidelines for ASP.NET controls?ASP.NET 控件的命名准则是什么？
【发布时间】：2010-09-15 22:42:33
【问题描述】：

我们正在制定我们希望在我们的开发团队中使用的设计指南，并在今天就如何命名 ASP.NET 控件展开了讨论。我说的是我们的好朋友Label、TextBox、Button等。

我们对以下三种可能性进行了投票：（示例是用于输入/显示名字的文本框）

将控件类型作为后缀添加到控件 ID：[FirstName_TextBox] 或 [FirstName_tbx]
将控件类型作为前缀添加到控件 ID [tbxFirstName]
将控件的 ID 设置为 FirstName 和名称相关字段（如文本框的标签或验证器），如选项 2 [lblTextBox] 中所示。

我们最终决定使用选项 2。它不像选项 1 那样冗长，我喜欢它在控件名称之前指定它是什么控件。

我的问题是，Microsoft 是否针对这些前缀发布了任何指南，或者您是否对我们的决定有任何意见。

【问题讨论】：

TextBox_FirstName 怎么样？我相信，无需在 IntelliSense 中发明前缀 + 最佳排序。
"TextBox_" 本身就是一个前缀。这与使用“tbx”没有什么不同。这个主题是如此开放，几乎任何适合你的东西都可以。微软本身似乎在他们发布的所有内容中都反对前缀（我听说他们确实在其内部代码中使用前缀！多么讽刺！）。我发现前缀非常有用，但是，就像下面有人回答的那样，如果您决定将控件更改为其他东西（即 tbxSomething => ddlSomething），则不应让它们干扰。只需将它们统称为 ctlSomething 或 uxSomething，这样您就不必过多地修复代码。

标签： asp.net naming-conventions coding-style

【解决方案1】：

不太确定是否有任何指导方针，我怀疑有，但我也总是使用数字 2！

【讨论】：

在他的问题中，他列出了 3 个选项，第 2 个是第二个。

【解决方案2】：

这些实际上只是基于您的偏好，但是是的，所描述的选项 2 不那么冗长，甚至在显示控件名称之前就向您指示控件的类型。

【讨论】：

【解决方案3】：

我们也使用数字 2，但我并不完全相信这是一个好方法。这是来自“坏”种类的匈牙利符号，这意味着前缀表示类型（语法）而不是目的（语义）。这样做的问题是，从 TextBox 开始的内容可能后来会变成 DropDown，然后是 RadioButtonGroup，并且您每次都必须重命名控件。

【讨论】：

我明白你的意思，我们确实讨论过使用 ui 或 ux 作为前缀，这可以解决这个问题，但是恕我直言，它使它变得不那么有用了。
控件是我仍然使用“坏”匈牙利符号的唯一地方，因为我发现它在区分控件和“真实”变量方面的好处多于坏处。至于如果您更改控件类型会更改名称，我认为这实际上是一件好的事情，因为例如 TextBox 和 DropDown 的方法和属性可能完全不同。如果您确实更改了控件类型，那么更改名称是一种简单的方法，可以在您的代码中查找假定旧类型的任何潜在问题区域。
真的，使用查找和替换重命名控件有多难？

【解决方案4】：

几乎每个人都使用匈牙利风格的前缀（选项 2）。语义命名不太有用，因为“名字”实际上是 texbox.Text 值，而不是文本框本身。

【讨论】：

【解决方案5】：

我更喜欢选项 1 的两个原因：

FirstNameTextBox 更符合我的业务对象。
更适用于 IntelliSense。

由于 csgero 指出更改控件类型的原因，我正在考虑更改为 FirstNameCtrl。那么为什么要使用任何后缀或前缀来减少/消除与 asp/win 表单属性冲突的可能性。

【讨论】：

保留全名。放弃考虑！

【解决方案6】：

不确定微软的官方标准，但这是我在整个开发生涯中所做的。

我一般在控件名称前面缩写控件类型。我保留缩写小写和控件的名称 CamelCase。

例如用户名的 texbox 变为 tbUserName

这是我使用的标准缩写列表：

Abbr     -  Control

btn  -  Button
cb   -  CheckBox
cbl  -  CheckBoxList
dd   -  DropDownList
gv   -  GridView
hl   -  Hyperlink
img  -  Image
ib   -  ImageButton
lbl  -  Label
lbtn -  LinkButton
lb   -  ListBox
lit  -  Literal
pnl  -  Panel
ph   -  PlaceHolder
rb   -  RadioButton
rbl  -  RadioButtonList
txt  -  Textbox

【讨论】：

我这样做的原因是智能感知将类似控件组合在一起，因此当您寻找正确的标签时，所有标签都在一起。我要补充一点，我所有的用户控件都以 uc 为前缀，所以我可以清楚地看到它们。

【解决方案7】：

我不确定有关 ASP.NET 的指南，但在 Microsoft 的框架设计指南一书中，有几个关于类成员命名的最佳实践指南。由于 ASP.NET 控件在大多数情况下会生成适当类型的受保护字段，因此我认为这些命名准则也适用于 ASP.NET 控件。事实上，代码分析并没有区分控件引用字段和其他字段。

这些指南建议使用暗示逻辑用途的命名方案，而不是类型描述变体。有几个原因。前缀对开发人员意味着一种类型，由于以后的更改可能不正确。它在代码维护中增加了一个额外的步骤。如果您将 Button 控件更改为 LinkButton 控件，则还需要更改名称以更正前缀。

出于这个原因，我会调用控件 FirstNameEdit 等...

【讨论】：

【解决方案8】：

我倾向于使用控件类型作为前缀，然后使用控件名称，但我总是使用 CamelCase，因此在您的示例中，您可能拥有不同类型的控件..

TxbFirstName
DdFirstName
ChbFirstName

出于智能感知的原因，我也总是完全限定控件的名称，因此我不会执行以下任何操作...

TxbFName
TxbClientNo
TxbNoOfCpn

但最终取决于个人喜好

【讨论】：

更新：我认为它是什么类型的控件很重要，如果我知道它是什么控件类型，我就知道要定位哪个属性值（Value、Selected、SelectedValue、SelectedItem.Text.. . etc etc etc），如果我不确定，则不必返回到 aspx 文件。

【解决方案9】：

我也一直在努力解决这个问题。我曾经使用“匈牙利风格前缀”。

现在我采用不同的方法，我尝试将控件视为我班级的私有字段。我不会在我的私有字段后面加上它们的类型，那么我为什么要对 TextBox 这样做呢？

原来是这样的：

var newCustomer = new Customer();
newCustomer.Name = txtName.Value;
newCustomer.Address = txtAddress.Value;
newCustomer.City = txtCity.Value;
newCustomer.HasEnoughMoney = cbHasMoney.Selected;

变成：

var newCustomer = new Customer();
newCustomer.Name = name.Value;
newCustomer.Address = address.Value;
newCustomer.City = city.Value;
newCustomer.HasEnoughMoney = hasMoney.Selected;

说实话，我不在乎“名称”控件是文本框还是其他什么，我只想要它的价值。

如果您在谈论您的控件或另一个字段/变量时不够清楚，我认为您应该重新考虑该字段/变量的名称或您的类的功能（这意味着它可能有点大吗？）。

【讨论】：

【解决方案10】：

如果您从代码维护的角度来看待它，那么在您 2 年前编写代码之后，最好的表示法是什么。尽管我们尝试确保表单上没有太多字段，但我们都知道有时会发生这种情况。如果我们通过添加控件类型来使用匈牙利类型表示法，我认为更容易看到该值的来源，而不必在变量名称不明显的情况下弄清楚它。如果您使用任何类型的重构工具，那么更改控件的名称将自动更改代码，从而减少更改控件的争论。

【讨论】：

+1 建议查看 2 年前的代码并了解如何改进并使其更易于阅读。

【解决方案11】：

我发现大多数时候我关心的是控件用于什么类型的信息，而不是当前用于捕获该数据的控件类型，所以我更喜欢控件类型之前的信息类型，所以我可以在 IDE 的排序列表中找到它：

AgeRangeDropDownList
AgreeToTermsCheckBox
名字文本框
姓氏文本框

VS：

chkAgreedToTerms
ddlAgeRange
txtFirstName
txtLastName

【讨论】：

这种方法需要更多的输入并在智能感知中产生“噪音”，因为不是服务器端控件的其他变量将显示在智能感知中。据推测，没有其他变量以 txt、dd 等开头，因此当您键入该前缀时，您通常只会看到您正在寻找的服务器端控件。
该方法更适合阅读/维护代码，而不是仅用于编写代码。
+1 为了便于阅读。您会将服务器控件视为实际对象而不是二等公民

【解决方案12】：

我认为这里没有正确或错误的答案，无论你决定什么，我认为最重要的方面就是在实际编码时保持一致。

【讨论】：

【解决方案13】：

Microsoft 确实在此处提供了一些指导。

当您将控件拖到 Web 表单上时，您会自动获得类似“TextBox1”的内容。那是 IDE 告诉您应该根据您的特定需求更改“1”部分。

在这种情况下，“TextBoxFirstName”似乎是可行的方法。

【讨论】：

【解决方案14】：

Visual Studio 在您将“TextBox1”添加到页面时添加它的原因是因为 Microsoft 无法知道您打算如何使用它。将其命名为“Control1”会过于混乱，因为它可以是任意数量的控件。

Microsoft 提供了针对 OO 命名约定的一般指南，但没有专门针对 UI 控件的命名。由于 UI 控件最终是代码中使用的变量，因此它们应遵循与任何其他变量相同的约定 - 没有匈牙利符号前缀。

主要原因是……

控件类型可能会从文本框更改为列表框，然后必须修复所有相关代码（如前所述）
您的代码应该更关心控件的内容，而不是它是什么类型的控件。当您关心控件的类型时，您开始依赖某些功能并且破坏了封装 - 您应该能够轻松地交换控件而无需更改太多或任何代码。（OOP 基本原理）
为标准控件提供前缀相当容易，但每天都在开发新控件。您可以制作自己的 WebUserControl，也可以购买一套第三方控件。 您将如何决定为自定义控件使用哪个前缀？您的代码不应关注控件的类型，而应关注其中包含哪些信息。

例子

txtFirstName => 名字或名字
txtState => 州或州
cboState => state 或 State（更改控件类型的主要示例 lstState 或 rdoState - 它们都应该具有相同的名称，因为您的代码不关心控件的类型，而是用户选择的状态）李>
ctlBilling => billingAddress 或 BillingAddress （自定义控件 - 使用匈牙利表示法，它甚至不是很明显控件是什么，但有了一个有意义的名称，我开始理解其中包含的信息。即 billingAddress.Street、billingAddress.FullAddress等）

【讨论】：

+1 并接受了提供 Microsoft 指导背后的链接和解释的答案。仍然不确定我们是否会放弃前缀选项，纯粹是因为智能感知。
如果您想一想 intellisense 的作用，您会发现在静态类型语言中声明变量名称中的类型是完全多余的，intellisense 能够提供此信息等等.
验证控件呢？或者在页面可能有一个 UserName 属性然后还有一个 UserName 控件的情况下？
我不支持或反对它，但我有一个相当不错的老板，他的意见是关于智能感知，他真正想要的是他所有的 UI 元素组合在一起。因此，他以“ux”为前缀。所以 TxtFirstName --> uxFirstName.

【解决方案15】：

我认为最好使用选项 1，因为通过它的含义和用法很容易找到该字段，以了解以后的编程编码。此外，使用 IntelliSense 来查找我们在编程代码中使用此字段的位置更有用。因此，我可以通过有意义的字段名称找到正确的控件。我不记得我对这个字段使用了什么样的控件，但是我可以通过使用有意义的字段名称而不是控件的类型来找到这个字段我想找到“城市”控件，我只输入“城市”，Intellisence将向我显示此控件的所有信息，但如果我不记得我使用哪种控件，我不知道从什么开始....

【讨论】：

【解决方案16】：

我使用 uxCity 是为了让您知道它绝对是用户界面控件而不是其他对象，但如果您从 TextBox 转到 DropDownList，则无需更改它。

但是，如果我有一个 DropdownList 和一个文本框，我需要使用 dlCity 和 txtCity 或者我会使用组合 cboCity。

当您被限制为 8 个字符的名称并且没有智能感知或调试突出显示时，匈牙利表示法是必要的。这是一门学科，您可以看到，如果编码风格正确，则代码很可能是正确的。它也用于变量，因此您可以阅读代码并理解它，因为它是一种 DIY 类型强制执行。

但是，我确实使用 CityTextbox、CityTextboxLabel CityUx, CityUxLbl

这完全取决于谁在为项目制定标准。

【讨论】：

【解决方案17】：

Abbreviation    ||   ASP.NET Control

标准控制：

btn 按钮

cb 复选框

cbl CheckBoxList

ddl 下拉列表

fu 文件上传

hdn 隐藏字段

lnk 超链接

img 图片

ibtn(btn) 图像按钮

lbl 标签

lbtn(btn) 链接按钮

磅列表框

字面量

mv 多视图

pnl 面板

ph 占位符

rb 单选按钮

rbl RadioButtonList

tbl 表

txt 文本框

v 查看

数据控制

dtl 数据列表

dp 数据分页器

dtv 详情查看

ets EntityDataSource

fv 窗体视图

gv 网格视图

lds LinqDataSource

lv - 列表视图

ods 对象数据源

qe 查询扩展器

rpt 中继器

smd SiteMapDataSource

sds SqlDataSource

xds XmlDataSource

验证控制

cpv 比较验证器

ctv 自定义验证器

rv 范围验证器

rev 正则表达式验证器

rfv 必填字段验证器

vs 验证摘要

验证控制：

cpv // 比较验证器

ctv 自定义验证器

rv 范围验证器

rev 正则表达式验证器

rfv 必填字段验证器

【讨论】：

【解决方案18】：

我发现使用匈牙利表示法的唯一原因是 IDE 没有智能感知，而且很难弄清楚是什么所以 iCounter 是一个整数

然而使用brief开发的时代已经一去不复返了，IDE会在一秒钟内显示信息

那你继承了VB.NET代码，不区分大小写怎么办？

lblFirstName, txtFirstName 一个是标签，另一个是文本框

那么你如何在不区分大小写的情况下命名它们并真正知道它们是什么？

uxFirstName 和 uxFirstName 不起作用

我找到的唯一答案是使用匈牙利符号，是的，我吐在嘴里。然后是它的 vb.net，它应该区分大小写，因为 .net 是并且所有编译到 IL。

【讨论】：