textBoxEmployeeName vs employeeNameTextBox - PullRequest
Новая
       30

textBoxEmployeeName vs employeeNameTextBox

13 голосов
/ 13 января 2009

Какое соглашение об именах вы используете и почему?

Мне нравится использовать employeeNameTextBox, потому что:

  • Это кажется более естественным с точки зрения английского языка.
  • Я считаю, что с Intellisense поискать проще.
  • Соглашение аналогично соглашению, используемому для событий (MouseClickEvent, MouseClickEventHandler) и свойств зависимостей (VisiblityProperty).

Примечание: я использую полное имя, а не аббревиатуру (например, "tb"), потому что это соответствует соглашениям MS по присвоению имен, в которых говорится, что следует избегать использования сокращений.

http://msdn.microsoft.com/en-us/library/ms229045.aspx

Ответы [ 16 ]

8 голосов
/ 13 января 2009

Единственная причина, по которой сначала следует использовать тип элемента управления в имени (textBoxEmployeeName), заключается в упрощении группировки с помощью Intellisense (тогда все элементы управления текстовым полем отображаются вместе). Помимо этого, на самом деле нет никакой пользы от использования этого способа. Я нахожу второй способ (employeeNameTextBox) более читабельным и предпочитаю этот путь лично, но многие все равно сначала будут использовать тип элемента управления, так как это было сделано в течение длительного времени.

4 голосов
/ 14 января 2009

Называть ваши переменные так важно. Толстые клиентские соглашения, кажется, дают короткий конец палки. Вот мои мысли:

  1. Никогда не размещайте методы получения и установки реальных бизнес-ценностей на ваш взгляд. Не делай этого: 

    public Name EmployeeName { get; set; }

  2. Чтобы получить или установить EmployeeName, ваш код с состоянием должен явно вызывать метод. Сделайте это так, потому что он проецирует, что состояние не сохраняется в представлении, но может быть получено из или преобразовано в представление: 

    public void SetEmployeeName(Name employeeName);
public Name GetEmployeeName();

  3. Венгерская запись глупа. Это было полезно в языках <= VB6, потому что они использовали позднее связывание типов переменных. Вы должны были защитить себя, потому что несоответствия типов были ошибками во время выполнения, а не во время компиляции. Используйте <code>txtEmployeeName только если вы также используете strEmployeeName и intEmployeeNumber.

  4. Если префикс имени шаблона не соответствует вашему соглашению об именах, не делайте этого для типа элемента управления (который представляет шаблон). Если вы не создадите commandNameFormatting (вместо nameFormattingComamnd), не создавайте textBoxEmployeeName.

  5. Вероятно, вам понадобится какой-то суффикс, поскольку EmployeeName недостаточно описывает назначение переменной. Цель текстового поля EmployeeName - получать входные данные. Вы можете назвать это EmployeeNameTextBox, если вам это удобно, но лучше было бы назвать это EmployeNameInput. Это дает дополнительный бонус: если у вас есть ярлык, ясно, что EmployeeNamePrompt (или EmployeeNameLabel) не совпадает с текстовым полем. Без какого-либо описательного суффикса у вас нет хорошего способа различить.

3 голосов
/ 13 января 2009

Я (почти) всегда использую [controltype] [описательное имя]. Я хочу сразу узнать, с каким типом управления я имею дело, когда смотрю на код, и если я не помню имя, intellisense может мне помочь.

Просто использование описательного имени (EmplyeeName) не работает для меня. Какой тип контроля? Это метка, текстовое поле или поле со списком? Или строка? Или файл? Достаточно важно, чтобы тип элемента управления или переменной всегда был его частью.

2 голосов
/ 02 марта 2010

Я предлагаю третий вариант: uiEmployeName. Причины:

  1. Это не венгерский. Обе обозначения, которые вы упомянули, - это только венгерские ароматы.
  2. Если вы измените текстовое поле имени сотрудника на список, вам не нужно переименовывать переменные.
  3. Все хорошо сгруппировано в intellisense, без учета типа объекта.
  4. Название объекта близко следует его функции. Это пользовательский объект, который получает имя сотрудника.
2 голосов
/ 13 января 2009

Обычно я стараюсь, чтобы тип элемента был коротким, за которым следует отличительная метка. Я считаю, что он быстро сообщает тип и назначение элемента: 

txtEmployeeName;
lblEmployeeName;
1 голос
/ 19 августа 2015

Полагаю, лучше придерживаться Соглашения об именовании объектов Microsoft для именования элементов управления как в C #, так и в Visual Basic.

1 голос
/ 02 марта 2010

Ответ, специфичный для WPF: вообще без имени.

Почему? Потому что, если вы разрабатываете с использованием WPF, вы не должны называть свои элементы управления. Если да, то вы делаете что-то не так.

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

1 голос
/ 14 января 2009

ОБЯЗАТЕЛЬНО ПРОЧИТАЙТЕ Рекомендации XAML , выпущенные Хайме:

Также читайте больше здесь

1 голос
/ 14 января 2009

Насколько я понимаю, в статье, на которую есть ссылка в статье, упомянутой в вопросе (а именно, Имена ресурсов ), в конце используется тип элемента управления, в FileMenu (и ArgumentException хотя это не контроль).

Мое личное мнение таково, что это также более читабельно, так как это текстовое поле имени сотрудника и, следовательно, должно называться employeeNameTextBox, точно так же, как слова «Файл меню» читаются в таком порядке. (Хотя я заменил «Edit» на «TextBox» для краткости & ndash; мне, вероятно, следует отказаться от этой привычки использовать имена элементов управления в соответствии с именем среды для них.)

1 голос
/ 13 января 2009

Почему не EmployeeName? Серьезно, как тип элемента управления как часть имени, если он уже предоставлен вашей IDE, помогает в предоставлении простого в обслуживании кода? Рассмотрим правила Оттенгера для именования переменных и классов

K

Страница:
...