Соглашения об именах элементов интерфейса WPF

Ответ 1

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

В Windows Forms каждый элемент управления был указан по имени в коде. С большим пользовательским интерфейсом полувариантная нотация была полезна - легче было отличить то, с чем вы работали.

В WPF, однако, это редкий элемент управления, которому требуется имя. Когда вам нужно получить доступ к элементу управления с помощью кода, часто лучше использовать приложенные свойства или поведения, чтобы сделать это, и в этом случае вы никогда не имеете дело с более чем одним элементом управления. Если вы работаете в коде UserControl или Window, я бы просто использовал "Title" и "Name" вместо "txtTitle", тем более, что теперь вы, вероятно, будете иметь дело только с несколькими ограниченными элементами управления всех из них.

В большинстве случаев даже пользовательские элементы управления не нуждаются в именах. Вам понадобятся шаблонные имена по следующему соглашению (например: PART_Name), но не фактические элементы x: Name для ваших пользовательских интерфейсов...

Ответ 2

По моему опыту. В WPF при изменении типа элемента управления обычно не нужно переписывать код, если вы не сделали что-то неправильно. Фактически, большую часть времени вы не ссылаетесь на элементы управления в коде. Да, вы это делаете, но большинство ссылок на элемент пользовательского интерфейса в WPF - это другие элементы в одном XAML.

И лично я считаю, что "lblTitle, lblCompany, txtFirstName" труднее читать, чем "Заголовок". У меня нет .intwidth и .intHeight(прощай lpzstrName!). Почему есть .lblFirstName? Я могу понять TitleField или TitleInput или что-то еще, так как он описывает, что, а не как.

Для меня, желая иметь такой тип разделения, обычно означает, что мой код пользовательского интерфейса пытается сделать слишком много - конечно, он имеет дело с элементом пользовательского интерфейса, он в коде окна! Если я не имею дело с кодом вокруг элемента пользовательского интерфейса, почему в мире я буду его кодировать здесь?

Ответ 3

Мне нравится использовать соглашение (просто хорошая идея в целом), но для файлов UI мне нравится иметь тип элемента управления спереди, а затем описательное имя - LabelSummary, TextSummary, CheckboxIsValid и т.д.

Это звучит незначительно, но главная причина, поместив сначала, состоит в том, что они появятся вместе в списке Intellisense - все метки вместе, флажки и т.д.

Ответ 4

Даже с точки зрения Winforms мне не нравится полу-венгерский.

Самый большой недостаток, на мой взгляд, и я написал много кода ui, что венгерский делает ошибки сложнее обнаружить. Компилятор, как правило, подбирает его, если вы попытаетесь изменить свойство checked в текстовом поле, но оно не будет воспринимать что-то вроде:

lblSomeThing.Visible = someControlsVisible;
txtWhatThing.Visible = someControlsVisible;
pbSomeThing.Visible = someControlsVisible;

Мне гораздо проще отлаживать:

someThingLabel.Visible = someControlsVisible;
whatThingTextBox.Visible = someControlsVisible;
someThingPictureBox.Visible = someControlsVisible;

Я также считаю, что лучше добавить группу addCommentsButton с addCommentsTextBox, чем группировать btnAddComments с помощью btnCloseWindow. Когда вы собираетесь использовать последние два вместе?

Насколько я могу найти контроль, я согласен с Филиппом Риком. Я часто хочу иметь дело со всеми элементами управления, которые относятся к определенной логической концепции (например, название или добавление комментариев). Я почти никогда не хочу находить только те или иные текстовые поля, которые находятся на этом элементе управления.

Возможно, это не имеет значения в WPF, но я думаю, что венгерского всегда следует избегать.

Ответ 5

Согласитесь с другими ответами, что это главным образом личное предпочтение, и самое главное - просто быть последовательным.

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

Ответ 6

В WPF вам практически не нужно (или даже хотеть) назвать свои элементы управления. Поэтому, если вы используете передовые методы WPF, не имеет значения, что бы вы назвали вашими элементами управления, если бы у вас была причина их имени.

В тех редких случаях, когда вы действительно хотите дать контроль над именем (например, для ElementName = или TargetName = reference), я предпочитаю выбирать имя, описывающее на основе цели имени, например:

<Border x:Name="hilightArea" ...>
   ...

<DataTrigger>
   ...
   <Setter TargetName="hilightArea" ...

Ответ 7

I префикс любого имени пользовательского интерфейса с двумя символами подчеркивания, как в __, поэтому он сортируется перед другими свойствами при отладке. Когда мне нужно использовать IntelliSense для поиска элемента управления, я просто набираю __ и список элементов управления. Это продолжает соглашение об именах для префикса единственного подчеркивания для переменных уровня модуля, как в int _id;.

Ответ 8

Вы можете использовать официальный веб-сайт Microsoft для соглашений об именовании элементов управления Visual Basic 6 и, возможно, объединить его с рекомендуемыми соглашениями об именах С#. Он очень специфичен, широко используется разработчиками в С#, а также для управляющих имен и все еще может использоваться в контексте WPF или Windows Forms.

Соглашения об именовании элементов управления Visual Basic 6: Соглашения об именах объектов

Рекомендуемые соглашения об именах С#: Общие соглашения об именах