Как назвать элементы GUI? - PullRequest
Новая
       9

Как назвать элементы GUI?

2 голосов
/ 31 января 2010

Одна вещь, которая постоянно вызывает у меня головную боль в программировании, это когда у меня нет соглашения об именах в области, где мне приходится иметь дело с большим количеством элементов. Это ясно, что происходит со мной при использовании дизайнеров пользовательского интерфейса, таких как дизайнер Windows Forms.

Каждый раз, когда я начинаю новый проект, я пытаюсь изобретать «кажущееся сильным» соглашение об именах, но в некоторых моментах оно всегда терпит неудачу. Для меня есть две основные проблемы по сравнению с классическим определением кода для именования элементов GUI:

  • Вам нужно разместить множество переменных (элементов GUI), к которым все могут быть доступны в одной и той же области видимости, поэтому для быстрого поиска нужного элемента вам необходимо строго соблюдать соглашение об именах.
  • Вам часто требуется доступ к определенному типу элемента управления графическим интерфейсом (например, TextBox, Label, ...), поэтому лучшим решением для элементов графического интерфейса является присвоение им имен по типам (нотация в венгерском стиле), что может быть иногда сбивает с толку и не помогает быстро найти нужный элемент.

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

Примечание: я не классифицировал этот вопрос как теги .NET или Windows Forms, кажется, он применим ко многим фреймворкам. Если нет, дайте мне знать.

EDIT:

Фактически, соглашение, которое я чаще всего использую, заключается в использовании обратной венгерской нотации (имеется в виду, что тип идет первым), за которой следует путь, основанный на иерархии элементов пользовательского интерфейса. Например, чтобы легко получить доступ к TextBox, который принадлежит вкладке «Настройки» моей программы, я бы назвал его так: 

this.tb_settingTab_xxx

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

Я действительно ищу нерушимое и удобное соглашение об именах. Я весьма удивлен, что Microsoft никогда не давала никаких рекомендаций относительно этого. Или я ошибаюсь? (т.е. комментарий Марка Рушакова).

Ответы [ 2 ]

2 голосов
/ 31 января 2010

Существуют различные соглашения об именах, описанные в this post. Ключ должен оставаться последовательным на протяжении всего проекта. Я имею дело с большим количеством элементов управления, но считаю простым обозначить их в зависимости от того, что они собой представляют. Textbox = tbMyControl, Label = lblMyControl. Бит «MyControl» может быть одинаковым, если он относится к аналогичным аспектам (например, tbUsername, lblUsername). Тем не менее, нет никакой путаницы в том, что я получаю доступ. Если вы обнаружите, что запутались, то, возможно, вы пытаетесь использовать слишком много разных обозначений? Сохраняйте это простым и логичным.

1 голос
/ 31 января 2010

Примечание: я использую следующее в коде, который охватывает - и иногда смешивает - "сырые" Win32, ATL / WTL и MFC, так что не воспринимайте это буквально, только принцип. (Кроме того, простите за m_)

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

CStatic m_stBasePath;
CEdit   m_edBasePath;
CButton m_cbBrowseBasePath;

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

Я написал три абзаца, которые можно было бы назвать «подробности и защита», и впоследствии удалил их, поскольку есть очень ясная суть:

Последовательность .

Я в основном использую сам ресурс диалога для ориентации и имею строгую эквивалентность между идентификаторами ресурса и связанными членами. Таким образом, элементы управления, связанные с «Базовым путем», расположены не в алфавитном порядке, но я редко рассматриваю это как проблему.

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

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

...