ASP.NET控件的命名准則是什么？

Question

我們正在制定我們希望在開發團隊中使用的設計指南，並在今天就如何命名ASP.NET控件進行討論。 我在談論我們的好朋友Label，TextBox，Button等。

我們提出了以下三種投票方式:(示例是輸入/顯示FirstName的TextBox）

1. 將控件類型作為后綴添加到控件ID：[FirstName _ TextBox]或[FirstName _ tbx]
2. 將控件類型添加為控件ID [tbxFirstName]的前綴
3. 將控件的ID設置為FirstName和名稱相關字段（如文本框或驗證器的標簽），如選項2 [lblTextBox]中所示。

我們最終決定使用選項2.它不像選項1那么冗長，我喜歡它指定控件名稱之前的控件。

我的問題是微軟是否已經發布了這些前綴的指南，或者如果您對我們的決定有任何意見。

Answer 1

將Studio添加到頁面時Visual Studio添加“TextBox1”的原因是因為Microsoft無法知道您打算如何使用它。 將其命名為“Control1”會讓人感到困惑，因為它可能是任意數量的控件。

Microsoft一般為OO命名約定提供指導，但不是專門用於命名UI控件。 由於UI控件最終是代碼中使用的變量，因此它們應遵循與任何其他變量相同的約定 - 沒有匈牙利語符號前綴。

• msdn.microsoft.com/en-us/library/xzf533w0(vs.71）
• msdn.microsoft.com/en-us/library/ms229002(VS.80）

主要原因是......

• 控件類型可能會從文本框更改為列表框，然后必須修復所有相關代碼（前面提到）
• 您的代碼應該更關注控件的內容，而不是它控制的類型。 當您關心控件的類型時，您開始依賴於某些功能並且您打破了封裝 - 您應該能夠輕松地交換控件而無需更改太多或任何代碼。 （基本OOP原則）
• 為標准控件提供前綴相當容易，但每天都在開發新的控件。 您可以創建自己的WebUserControl，也可以購買一組第三方控件。 您將如何確定用於自定義控件的前綴？ 您的代碼應該關注其中包含的信息，而不是關注控件的類型。

例子

• txtFirstName => firstName或FirstName
• txtState =>州或州
• cboState => state或State（更改控件類型的主要示例如何關於lstState或rdoState - 它們應該都具有相同的名稱，因為您的代碼不關心控件的類型，而是用戶選擇的狀態）
• ctlBilling => billingAddress或BillingAddress（自定義控件 - 使用匈牙利表示法控制甚至不是很明顯，但是有一個有意義的名稱我開始理解其中包含的信息。即billingAddress.Street，billingAddress.FullAddress等）

Answer 2

不確定微軟的官方標准，但這是我在整個開發過程中所做的。

我通常在控件的名稱前面縮寫控件類型。 我保留縮寫小寫和控件名稱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

Answer 3

我發現大多數時候我關心控件的信息類型而不是當前用於捕獲數據的控件類型，所以我更喜歡控件類型之前的信息類型，所以我可以在IDE中的排序列表：

• AgeRangeDropDownList
• AgreedToTermsCheckBox
• FirstNameTextBox
• LastNameTextBox

VS：

• chkAgreedToTerms
• ddlAgeRange
• txtFirstName
• txtLastName

Answer 4

Microsoft確實提供了一些指導。

將控件拖到Web表單上時，會自動獲得類似“TextBox1”的內容。 這是IDE告訴您應該根據您的特定需求更改“1”部分。

在這種情況下，“TextBoxFirstName”似乎是要走的路。

Answer 5

我更喜歡選項1的兩個原因：

1. FirstNameTextBox與我的業務對象更緊密地匹配。
2. 更易於使用IntelliSense。

說過我正在考慮更改為FirstNameCtrl，因為csgero指出了更改控件類型的原因。 那么為什么要使用任何后綴或前綴來減少/刪除與asp / win表單屬性沖突的可能性。

Answer 6

我不確定有關ASP.NET的指南，但在Microsoft的“框架設計指南”一書中，有幾個關於類成員命名的最佳實踐指南。 由於ASP.NET控件在大多數情況下會生成相應類型的受保護字段，因此我認為這些命名准則也適用於ASP.NET控件。 實際上，代碼分析不區分控制參考字段和其他字段。

這些指南建議使用隱含邏輯用途而非類型描述性變體的命名方案。 有幾個原因。 前綴意味着開發人員的類型可能由於以后的更改而不正確。 它增加了代碼維護的額外步驟。 如果將Button控件更改為LinkBut​​ton控件，則還需要更改名稱以更正前綴。

因此我會調用控件FirstNameEdit等...

Answer 7

Abbreviation    ||   ASP.NET Control

標准控制：

btn按鈕

cb CheckBox

cbl CheckBoxList

ddl DropDownList

fu FileUpload

hdn HiddenField

lnk超鏈接

img圖片

ibtn（btn）ImageButton

lbl標簽

lbtn（btn）LinkBut​​ton

lb ListBox

點燃文字

mv MultiView

pnl Panel

ph PlaceHolder

rb RadioButton

rbl RadioButtonList

tbl表

txt TextBox

v查看

數據控制

dtl DataList

dp DataPager

dtv DetailsView

ets EntityDataSource

fv FormView

gv GridView

lds LinqDataSource

lv - ListView

ods ObjectDataSource

qe QueryExtender

rpt中繼器

smd SiteMapDataSource

sds SqlDataSource

xds XmlDataSource

驗證控制

cpv CompareValidator

ctv CustomValidator

rv RangeValidator

rev RegularExpressionValidator

rfv RequiredFieldValidator

vs ValidationSummary

驗證控制：

cpv // CompareValidator

ctv CustomValidator

rv RangeValidator

rev RegularExpressionValidator

rfv RequiredFieldValidator

Answer 8

我認為最好使用選項1，因為很容易通過它的含義及其用途來找到該字段，以便了解編程編碼。 此外，它更適用於IntelliSense，以便在我們的編程代碼中找到我們使用此字段的位置。 因此，我可以通過有意義字段的名稱找到正確的控件。 我不會記得我對這個字段使用什么樣的控件但是我可以通過使用有意義的字段名稱而不是控件示例的類型來找到這個字段我想要找到“City”控件，我只是典型的“City”，Intellisence將告訴我這個控件的所有信息，但如果我不記得我用什么樣的控件，我不知道該怎么開始....

Answer 9

我使用uxCity，因此您知道它絕對是用戶界面控件而不是其他對象，但如果您從TextBox轉到DropDownList，則無需更改它。

但是，如果我有DropdownList 和 Textbox，我需要使用dlCity和txtCity或者我使用組合cboCity。

當您被限制為8個字符的名稱而沒有智能感知或調試突出顯示時，匈牙利符號是de rigeur。 這是一門學科，你可以看到，如果編碼風格是正確的，代碼可能是正確的。 它也被用於變量，所以你可以閱讀代碼並理解它，因為它是一種DIY類型的執行。

但是，我確實使用CityTextbox，CityTextboxLabel CityUx，CityUxLbl

這一切都取決於誰在制定項目標准。

Answer 10

我們也使用2號，但我並不完全相信這是一個好方法。 它是來自“壞”類型的匈牙利符號，意味着前綴表示類型（語法）而不是目的（語義）。 這個問題是以TextBox開頭的內容可能稍后變成DropDown然后變成RadioButtonGroup，並且每次都必須重命名控件。

Answer 11

幾乎每個人都使用匈牙利風格的前綴（選項2）。 語義命名不太有用，因為“Firstname”實際上是texbox.Text值，而不是文本框本身。

Answer 12

我傾向於使用控件類型作為前綴和控件的名稱，但我總是CamelCase所以在你的例子中你可能有不同類型的控件..

• TxbFirstName
• DdFirstName
• ChbFirstName

出於intellisense的原因，我也總是完全限定控件的名稱，所以我不會做以下任何一個...

• TxbFName
• TxbClientNo
• TxbNoOfCpn

但最終歸結為個人偏好

Answer 13

我也一直在努力解決這個問題。 我曾經使用過“匈牙利風格的前綴”。

現在我采取不同的方法，我嘗試將控件視為我班級的私有字段。 我沒有預先修改我的私有字段及其類型，所以我為什么要這樣做到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;

說實話，如果“名稱”控件是一個文本框或其他什么，我不在乎，我只是想要它的價值。

如果你談論你的控制或另一個領域/變量還不夠清楚，我認為你應該重新考慮那個領域/變量的名稱或你的類的功能（意味着它可能有點大？） 。

Answer 14

如果從代碼維護的角度來看，在2年前完成代碼之后，最好的符號是什么。 雖然我們試圖確保表單上沒有太多字段，但我們都知道這種情況有時會發生。 如果我們通過預先設置控件類型來使用匈牙利類型表示法，我認為更容易看到該值的來源，而不必在變量名稱不明顯的情況下弄清楚它。 如果您使用任何類型的重構工具，那么更改控件的名稱將自動更改代碼，從而減少更改控制爭論。

Answer 15

我不認為這里有正確或錯誤的答案，無論你決定什么，我認為最重要的方面是在實際編碼時保持一致。

Answer 16

我發現使用匈牙利表示法的唯一原因是IDE沒有智能感知並且要弄清楚什么是iCounter是一個整數並不容易

然而，使用brief進行開發的時間早已不復存在，IDE會在一秒鍾內向您顯示信息

然后你繼承了VB.NET代碼，它不區分大小寫，你怎么辦？

lblFirstName，txtFirstName一個是標簽，另一個是文本框

那么如何在沒有區分大小寫的情況下命名這些並實際知道它們是什么？

uxFirstName和uxFirstName不起作用

我找到的唯一答案是使用匈牙利表示法，是的，我吐在嘴里。 然后它的vb.net又應該區分大小寫，因為.net是和IL的所有編譯。

Answer 17

不確定任何准則，我懷疑有，但我也總是使用2號！

Answer 18

這些實際上只是基於您的偏好，但是，所描述的選項2不那么冗長，並且即使在顯示其名稱之前也向您指示控件的類型。