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

Question

Хотя Венгерская запись в настоящее время считается плохой практикой, все же довольно часто кодируют тип в названии элементов пользовательского интерфейса , либо используя префикс (lblTitle , txtFirstName, ...) или суффикс (TitleLabel, FirstNameTextBox, ...).

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

Итак, я думаю о том, чтобы придерживаться этой практики при начале разработки WPF (хммм ... мы должны использовать префикс txt для TextBlocks или TextBoxes?). Есть ли большой недостаток, который я пропустил? Это ваш шанс сказать: «Не делай этого, потому что ...».

РЕДАКТИРОВАТЬ: я знаю, что с привязкой данных необходимость называть элементы пользовательского интерфейса уменьшается. Тем не менее, иногда это необходимо, например, при разработке пользовательских элементов управления ...

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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

C # рекомендуемые соглашения об именах в целом: Общие соглашения об именах

Answer 7

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

Answer 8

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

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

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

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