TextBoxEmployeeName vs employeeNameTextBox

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

Я бы выбрал [controlType] [DomainTerm], который в данном случае textBoxEmployeeName. Причина в том, что при кодировании кода C# вы больше заботитесь об элементах управления пользовательского интерфейса, чем о конкретных терминах домена. Кодирование на стороне пользовательского интерфейса (представление) нам нужно быстрее идентифицировать / распознавать тип элемента управления, что немного важнее, чем домен конкретное имя на стороне просмотра, и поскольку мы читаем из 'Слева направо', это соглашение об именах актуально. Обычно я использую txtEmployeeName или cmpEmployeeType, но в соответствии с рекомендациями MS предпочтительнее использовать textBox вместо txt.

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

K

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

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

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

txtEmployeeName;
lblEmployeeName;

Я не рекомендую венгерские обозначения в какой-либо форме. textBoxEmployeeName - это форма венгерской нотации. Поэтому я поддерживаю использование employeeNameTextBox.

Лично я даже не использую слово TextBox, потому что это не то, что важно для переменной. Важны «Сотрудник» и «Имя». Добавление слова TextBox не только привязывает вас к определенному типу, но и значительно усложняет изменение этого типа, потому что вам нужно изменить имя, чтобы нормализовать ваш код и сделать его правильным. Скажем, по какой-то причине вы начали это как TextBox, но позже вы получили требование изменить это на DropDownList или какой-либо другой тип, теперь вам нужно обновить весь свой код и JavaScript, чтобы он говорил DropDownList вместо TextBox.

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

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

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

Имена ваших переменных очень важны. Кажется, что соглашениям о толстых клиентских представлениях не о чем беспокоиться. Вот мои мысли:

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

   public Name EmployeeName { get; set; }
   

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

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

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

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

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

Я использовал как txtEmployeeName, так и employeeNameTextbox. Как и многие из указанных сообщений, это полезно для группировки. Один группирует по типам элементов управления (txtEmployeeName, txtManagerName), а другой может группировать различные связанные элементы управления вместе (employeeNameTextbox, employeePhoneTextbox, managerNameTextBox, managerPhoneTextbox). Во многих случаях я считаю, что последнее более полезно при кодировании.

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

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

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

Идеи:

1. Избегайте кодировок / сокращений.

2. Название должно отличаться от похожие имена в той же области. Сделайте большую часть уникальной левая часть. Я подозреваю, что у тебя есть несколько текстовых полей, но только одно имя сотрудника.

3. Избегайте ненужного контекста. Все имена на этой странице о сотрудниках? Это страница "сотрудника"? потом EmployeeName является избыточным. NameBox или NameControl должно быть много.

4. Избегайте ненужного контекста: есть ли у вас имена, которые не являются элементами управления? Если так, "Коробка" или "Контроль" полезны, в остальном не так уж и много.

Раскрытие информации: я «ottinger» от «правил именования ottingers», которые также превратились в главу 2 «Чистого кода». См. Краткую форму на http://agileinaflash.blogspot.com/2009/02/meaningful-names.html

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

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

Ответ, относящийся к WPF: вообще без имени.

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

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

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

В VB мне нравится использовать [ControlName] _ [ControlType]. Я не могу вспомнить, как я начал это делать, но полагаю, это потому, что это похоже на логический порядок. Это также немного упрощает кодирование, поскольку предложения кода сгруппированы по описанию элемента управления, а не по типу элемента управления.

Я называю элементы управления таким же образом в C#, за исключением того, что я следую предпочтениям C# для camelCase: [controlName] _ [controlType].

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

Примеры:

VB:Save_Btn и NewFile_MItem (пункт меню)

C#:save_btn и newFile_mItem

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