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

Question

Мы находимся в процессе разработки рекомендаций по проектированию, которые мы хотели бы использовать в нашей команде разработчиков, и сегодня мы обсудили, как следует называть элементы управления ASP.NET. Я говорю о наших хороших друзьях Label, TextBox, Button и т. Д.

Мы предложили следующие три возможности, за которые проголосовали: (Например, TextBox для ввода / отображения FirstName)

1. Добавьте тип элемента управления в качестве постфикса к идентификатору элемента управления: [FirstName _ TextBox] или [FirstName _ tbx]
2. Добавить тип элемента управления в качестве префикса к идентификатору элемента управления [tbxFirstName]
3. Установите идентификатор элемента управления для FirstName и полей, связанных с именем (например, метка для текстового поля или валидатор), как в опции 2 [lblTextBox].

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

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

Answer 1

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

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

• msdn.microsoft.com / EN-US / библиотека / xzf533w0 (vs.71)
• msdn.microsoft.com / EN-US / библиотека / ms229002 (VS.80)

Основными причинами являются ...

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

Примеры * * 1 027

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

Answer 2

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

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

например. Текстовое поле для имени пользователя становится 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 предоставляет некоторые указания здесь.

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

В этом случае «TextBoxFirstName» выглядит как путь.

Answer 5

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

Answer 6

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

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

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

Answer 7

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

1. FirstNameTextBox более точно соответствует моему бизнес-объекту.
2. Больше подходит для IntelliSense.

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

Answer 8

Abbreviation    ||   ASP.NET Control

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

Кнопка BTN

cb CheckBox

cbl CheckBoxList

ddl DropDownList

fu FileUpload

hdn HiddenField

lnk Hyperlink

img Image

ibtn (btn) ImageButton

фунт метка

lbtn (btn) LinkButton

фунт ListBox

горит буквально

mv MultiView

Панель pnl

ph PlaceHolder

rb RadioButton

руб. RadioButtonList

Табл. Стол

TXT TextBox

v Просмотр

КОНТРОЛЬ ДАННЫХ

dtl DataList

dp DataPager

подробности dtv

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

р.в. RangeValidator

rev RegularExpressionValidator

rfv RequiredFieldValidator

Answer 9

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

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

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

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

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

Answer 10

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