Каковы руководящие принципы именования для элементов управления ASP.NET?

Ответ 1

Причина, по которой Visual Studio добавляет "TextBox1", когда вы добавляете ее на страницу, заключается в том, что Microsoft не знает, как вы собираетесь ее использовать. Именование его "Control1" было бы слишком запутанным, потому что это могло быть любое количество элементов управления.

Microsoft предоставляет общие рекомендации для соглашений об именах OO, но не специально для именования элементов пользовательского интерфейса. Поскольку элементы управления пользовательского интерфейса в конечном счете являются переменными, используемыми в коде, они должны следовать тому же соглашению, что и любая другая переменная - без префикса нотариальных обозначений.

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

Основные причины...

• Тип управления может меняться от текстового поля к списку, тогда все связанные с ним коды должны быть исправлены (отмечено ранее)
• Ваш код должен быть больше связан с содержимым элемента управления, а не с каким типом управления. Когда вы беспокоитесь о типе элемента управления, вы начинаете зависеть от определенных функциональных возможностей, и вы нарушаете инкапсуляцию - вы должны иметь возможность легко менять элементы управления, не меняя сильно или никакого кода. (Основной принцип ООП)
• Довольно легко придумать префиксы для стандартных элементов управления, но новые элементы управления разрабатываются каждый день. Вы можете создать свой собственный WebUserControl, или вы можете приобрести набор сторонних элементов управления. Как вы определяете, какой префикс использовать для пользовательских элементов управления? Вместо того, чтобы сосредоточиться на типе элемента управления, ваш код должен быть связан с тем, какая информация содержится в нем.

Примеры

• txtFirstName = > firstName или FirstName
• txtState = > состояние или состояние
• cboState = > состояние или состояние (простой пример изменения типов управления, что касается lstState или rdoState - все они должны иметь одинаковое имя, потому что ваш код не касается типа элемента управления, а не состояния, которое пользователь выбрал)
• ctlBilling = > billingAddress или BillingAddress (настраиваемый элемент управления - с венгерской нотацией не совсем очевидно, что элемент управления даже есть, но со значимым именем я начинаю понимать содержащуюся в нем информацию, то есть биллингAddress.Street, billingAddress.FullAddress и др.)

Ответ 2

Не уверен в официальных стандартах Microsoft, но это то, что я сделал в своей карьере развития.

Я обычно сокращаю тип управления перед именем того, что делает элемент управления. Я сохраняю аббревиатуру нижнего регистра и контрольное имя 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

Ответ 3

Я нахожу, что большую часть времени я забочусь о том, какая информация используется для управления, а не какой тип управления используется в настоящее время для захвата этих данных, поэтому я предпочитаю тип информации до типа управления, поэтому могу найти его в отсортированном списке в среде IDE:

• AgeRangeDropDownList
• AgreedToTermsCheckBox
• FirstNameTextBox
• LastNameTextBox

VS:

• chkAgreedToTerms
• ddlAgeRange
• txtFirstName
• txtLastName

Ответ 4

Microsoft предоставляет некоторые рекомендации здесь.

Когда вы перетаскиваете элемент управления в веб-форму, вы получаете что-то вроде "TextBox1" автоматически. Что IDE сообщает вам, что вы должны изменить часть "1" для ваших конкретных потребностей.

В этом случае "TextBoxFirstName" похоже на путь.

Ответ 5

Две причины, почему я предпочитаю вариант 1:

• FirstNameTextBox более точно соответствует моему бизнес-объекту.
• Больше можно использовать с IntelliSense.

Сказав, что я рассматриваю возможность изменения на FirstNameCtrl по той причине, что csgero указал на изменение типов управления. Итак, зачем беспокоиться о любых постфиксах или префиксах, чтобы уменьшить/удалить вероятность конфликтов с свойствами asp/win form.

Ответ 6

Я не уверен в рекомендациях по ASP.NET, но в книге "Руководства по дизайну рамок" от Microsoft существует несколько рекомендаций по наименованию членов класса. Поскольку ASP.NET Controls в большинстве случаев приводит к защищенному полю соответствующего типа, я считаю, что эти правила именования применяются для элементов управления ASP.NET. На самом деле Code Analysis не различает поля контрольных ссылок и другие поля.

В этих рекомендациях рекомендуется использовать схему именования, которая подразумевает логическое использование, а не тип-описательный вариант. На это есть несколько причин. Префикс подразумевает тип разработчика, который может быть неправильным из-за более поздних изменений. Он добавляет дополнительный шаг в поддержании кода. Если вы измените элемент управления Button в элементе управления LinkButton, имя также необходимо изменить, чтобы исправить префикс.

По этой причине я бы назвал элемент управления FirstNameEdit и т.д.

Ответ 7

Я думаю, что лучше использовать вариант 1, потому что легко найти поле по его значению и его использованию, чтобы понять программирование кодирования в будущем. Кроме того, более удобно использовать IntelliSense для поиска того, где мы используем это поле для нашего программного кода. Поэтому я могу найти правильный контроль по имени значимого поля. Я не буду вспоминать, какой контроль я использую для этого поля, но я могу найти это поле, используя значение имени поля вместо типа примера управления. Я хочу найти элемент управления "Город", я просто тип "Город", Intellisence покажет мне всю информацию для этого элемента управления, но если я не помню, какой контроль я использую, я не знаю, с чего начать...

Ответ 8

Abbreviation    ||   ASP.NET Control

СТАНДАРТНЫЕ ОРГАНЫ УПРАВЛЕНИЯ:

btn

cb CheckBox

cbl CheckBoxList

ddl DropDownList

fu FileUpload

hdn HiddenField

lnk Гиперссылка

img Изображение

ibtn (btn) ImageButton

lbl Метка

lbtn (btn) LinkButton

lb ListBox

lit Literal

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

Ответ 9

Мы также используем номер 2, однако я не совсем уверен, что это хороший подход. Это венгерская нотация из "плохого" вида, что означает, что префиксы сигнализируют тип (синтаксис), а не цель (семантика). Проблема заключается в том, что то, что начинается с TextBox, позже может стать DropDown, а затем RadioButtonGroup, и вам придется переименовывать элемент управления каждый раз.

Ответ 10

Почти все используют префиксы венгерского стиля (вариант 2). Семантическое именование менее полезно, потому что "Имя" - это фактически значение texbox.Text, а не текстовое поле.

Ответ 11

Я склонен идти с типом управления в качестве префикса и названия элемента управления, но я всегда CamelCase, поэтому в вашем примере для различных типов элементов управления, которые у вас могут быть.

• TxbFirstName
• DdFirstName
• ChbFirstName

По причинам intellisense я также всегда полностью квалифицирую имя элемента управления, поэтому я не сделал бы ничего из следующего...

• TxbFName
• TxbClientNo
• TxbNoOfCpn

Но в конечном итоге до личных предпочтений

Ответ 12

Я тоже борюсь с этой проблемой. Раньше я использовал "префикс венгерского стиля".

Теперь я использую другой подход, я пытаюсь увидеть элементы управления как частные поля из моего класса. Я не префикс postfix своих личных полей с их типом, поэтому зачем мне это делать с 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;

Честно говоря, мне было все равно, если "имя" - это текстовое поле или что-то еще, я просто хочу, чтобы оно было ценным.

И если это недостаточно ясно, если вы говорите о своем контроле или о другом поле/переменной, я думаю, вы должны либо пересмотреть имя этого поля/переменной, либо функцию вашего класса (что означает, что это может быть немного большой?).

Ответ 13

Если вы посмотрите на это с точки зрения поддержания кода, что было бы лучшим обозначением, которое можно было бы рассмотреть после того, как вы сделали код 2 года назад. Хотя мы стараемся обеспечить, чтобы в формах не было слишком много полей, мы все знаем, что это иногда случается. Если бы мы использовали нотацию венгерского типа, добавив тип управления, я думаю, было бы легче увидеть, откуда это значение, вместо того, чтобы понять это в случае, если имя переменной не делает его очевидным. Если вы используете инструмент рефакторинга любого типа, то изменение имени элемента управления автоматически изменит код, тем самым уменьшив аргумент управления изменениями.

Ответ 14

Я не думаю, что здесь правильный или неправильный ответ, независимо от того, что вы решите, я думаю, что самый важный аспект - быть последовательным, когда он действительно приходит к кодированию.

Ответ 15

Я использую uxCity, чтобы вы знали, что это определенно элемент управления User Interface, а не какой-либо другой объект, но вам не нужно его изменять, если вы переходите от TextBox к DropDownList.

Однако, если у меня был DropdownList и текстовое поле, мне нужно было бы использовать dlCity и txtCity Или я бы использовал комбо-cboCity.

Венгерская нотация была жесткой, когда вы были ограничены 8-символьными именами и отсутствовали подсветка intellisense или debug. Это была дисциплина, и вы могли видеть, что если стиль кодирования был правильным, код, вероятно, был бы правильным. Он также использовался для переменных, чтобы вы могли прочитать код и понять его, поскольку это было принудительное выполнение DIY.

Однако я использую CityTextbox, CityTextboxLabel CityUx, CityUxLbl

Все зависит от того, кто устанавливает стандарты в проекте.

Ответ 16

Я нашел единственную причину использования венгерской нотации в том, что в среде IDE не было intellisense, и было нелегко понять, что было таким, что iCounter был целым числом

Однако время использования краткого для разработки давно исчезло, и IDE показывает вам информацию в секунду

Затем вы наследуете код VB.NET и не чувствительны к регистру, так что вы делаете?

lblFirstName, txtFirstName Один - это метка, другая - текстовое поле

Итак, как вы называете их без чувствительности к регистру и действительно знаете, что они собой представляют?

uxFirstName и uxFirstName не работают

Единственный ответ, который я нашел, - это использовать венгерскую нотацию, да, я бросил в рот. Затем снова его vb.net и он должен быть чувствительным к регистру, поскольку .net есть и все компиляции в IL.

Ответ 17

Не уверен в каких-либо рекомендациях, я подозреваю, что есть, но я всегда использую номер 2!

Ответ 18

они действительно основаны на ваших предпочтениях, но да, вариант 2, как описано, менее подробен и указывает вам тип управления еще до того, как его имя будет показано.