Наилучшая практика для соглашения об именовании элементов управления пользовательского интерфейса для ссылки в коде позади? - PullRequest
7 голосов
/ 21 сентября 2008

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

Я разрабатываю много отчетов и форм в моем офисе. У меня есть несколько веб-приложений, предоставляющих около 80+ «живых» отчетов, генерируемых из различных источников данных (Access, SQL, Oracle). Эти отчеты считаются «живыми», поскольку они принимают параметры, заданные пользователем из формы, а затем запрашивают базу данных, чтобы создать отчет на основе текущей доступной информации.

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

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

Ответы [ 7 ]

7 голосов
/ 22 сентября 2008

Для элементов управления с графическим интерфейсом я добавляю суффикс имени переменной к имени элемента управления:

  • firstNameTextBox
  • lastNameTextBox
  • submitButton

Это делает связь очевидной, например, между _firstName и firstNameTextBox.Text, и никто не должен помнить, что такое венгерский эквивалент нотации. Я бы всегда выбрал ясность, а не краткость именования переменных.

7 голосов
/ 22 сентября 2008

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

btn Button
cbo ComboBox
chk CheckBox
clb CheckedListBox
grp GroupBox
iml ImageList
lbl Label
lnk Hyperlink
mnu Menu
pbr ProgressBar
pic Picture
pnl Panel
rtb RichTextBox
tmr Timer
tvw TreeView
txt TextBox
7 голосов
/ 22 сентября 2008

Основной продукт, над которым я работаю, использует префиксы txt_ pnl_ и т. Д. Это работает, хотя иногда бывает немного трудно переключать что-то, что просто скрывает / показывает элементы управления, скажем, tr на панель, потому что вы должны переименовать это.

То, что я начал делать в новых проектах, - это присвоение имен элементам управления пользовательского интерфейса с префиксом пользовательского интерфейса; например, uiName. Поскольку я категорически против анти-венгерской нотации и стремлюсь к самодокументируемому коду , это соглашение работает хорошо. Фактически, если что-нибудь, это реальная венгерская нотация (ui - префикс, означающий управление пользовательским интерфейсом).

3 голосов
/ 21 сентября 2008

Ваши ответы здесь будут очень субъективными. Различные вкусы и фоны программирования дадут вам разные предпочтения.

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

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

Вот несколько ссылок на соглашения об именах:

http://www.irritatedvowel.net/Programming/Standards.aspx

http://msdn.microsoft.com/en-us/library/xzf533w0(VS.71).aspx

http://www.visualize.uk.com/resources/asp-net-standards.asp

1 голос
/ 21 сентября 2008

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

Например:

TextBox -> tbName

DataGrid -> dgName

Панель -> pName

Это дает понять, как обрабатывать новые элементы управления (т.е. как получить префикс)

0 голосов
/ 14 октября 2017

префиксы с двумя символами для компонентов пользовательского интерфейса iOS, которые я предпочитаю:

bt_: UIButton
lb_: UILabel
tx_: UITextField
tv_: UITextView
vw_: UIView
im_: UIImageView
sc_: UIScrollView
tb_: UITableView
cl_: UICollectionView
st_: UIStackView
pk_: UIPickerView
pr_: UIProgressView
ai_: UIActivityIndicatorView
wb_: UIWebView / WKWebView
mp_: MKMapView
gr_: UIGestureRecognizer
sw_: UISwitch
sl_: UISlider
sp_: UIStepper
sg_: UISegmentedControl
pg_: UIPageControl
dp_: UIDatePicker

0 голосов
/ 22 сентября 2008

Я всегда чувствовал, что единственная реальная причина для префиксов состояла в том, чтобы вы могли иметь такие вещи, как txtFirstName и lblFirstName на одной и той же форме / странице. Поскольку в большинстве случаев я работаю только с самим полевым элементом управления, я пропускаю префикс для этого и использую только префиксы для связанных элементов управления. Например, lblMonth & Month, пропуская префикс cbo.

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

...