Каково рекомендуемое соглашение об именовании элементов управления для разметки XAML?

10

При работе с WPF или Silverlight, как использовать соглашения об именах? Вы называете элементы управления в разметке XAML? Я видел примеры проектов в codeplex с именами элементов управления, такими как «selectButton» или «btnSelect». Что бы вы порекомендовали?

wpf silverlight

— Мамта Д
источник

1

Какую бы схему вы ни выбрали - будьте последовательны во всем приложении.

— ChrisF

8

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

РЕДАКТИРОВАТЬ

Чтобы сделать это более понятным, Microsoft исключила венгерскую нотацию из всех своих соглашений об именах, включая элементы пользовательского интерфейса. ОДНАКО, MS не документировал никаких рекомендаций для элементов пользовательского интерфейса. Существует множество ссылок, которые отмечают это и предлагают свои предложения, но суть в том, что с элементами пользовательского интерфейса вы сами по себе. Пример ссылки .

В нашем стандарте мы удалили венгерскую нотацию и используем явное именование, означающее, что кнопка с именем OK будет называться ButtonOK, а текстовый блок с именем Comments будет TextblockComments. Недостатком является то, что имена могут быть довольно длинными, положительным является то, что ВСЕ точно знают, что это за элемент.

Пока вы устанавливаете, что работает для вас и последовательно используете этот стандарт, вы не ошибетесь.

— Вальтер
источник

2

Это рекомендации по именованию членов в библиотеках, а не элементов пользовательского интерфейса.

— Роберт Харви

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

— Уолтер

4

Я обычно не называю свои элементы управления в XAML, так как в большинстве случаев они не используются, учитывая, что все установлено или контролируется через привязки. Источник: Пит Браун

— Матье
источник

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

— Роберт Харви

@ Роберт Харви: Из статьи: «Интерактивные элементы управления пользовательского интерфейса, такие как TextBoxes, ListBoxes, Buttons и т. Д. Вы можете обойтись без именования, если вы используете команды / поведения и хороший шаблон, такой как MVVM, но я считаю, что присвоение имен полезно из с точки зрения документации. Не обязательно, но полезно. " Поскольку я работал с MVVM, и мне не нужно было сообщать мой xaml дизайнеру для смешанных работ, я не нашел никакого использования для этих имен. Мои элементы управления очень просты, документация, предоставленная этими именами, будет излишней. Но я согласен, что на более сложном интерфейсе он может быть другим.

— Матье

Я использую MVVM и редко называю свои элементы управления. Это довольно очевидно, что они по контексту и с дизайнером VS. Время от времени я буду помещать комментарий в XAML.

— М. Дадли

2

Я не знаю о XAML, но для обычного старого ASP.NET я видел следующие соглашения:

Старый добрый венгерский (например, txtFirstName, ddlState, chkAcceptsTerms)
Явное именование (например, TextFirstName, DropdownState, CheckAcceptsTerms)

Не уверен, что я предпочитаю, честно. Раньше я видел много кода вроде # 2, но в обратном порядке (например, FirstNameTex, StateDropdown, AcceptsTermsCheck), но мне нравится другой способ, так как он группирует связанные элементы управления вместе.

— Уэйн Молина
источник