textBoxEmployeeName vs employeeNameTextBox

Question

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

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

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

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

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

Answer 1

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

Answer 2

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

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) не совпадает с текстовым полем. Без какого-либо описательного суффикса у вас нет хорошего способа различить.

Answer 3

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

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

Answer 4

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

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

Answer 5

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

txtEmployeeName;
lblEmployeeName;

Answer 6

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

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

Answer 7

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

Answer 8

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

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

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

Answer 9

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

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

Answer 10

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

К

Answer 11

Идеи:

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

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

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

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

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

Answer 12

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

Answer 13

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

Answer 14

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

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

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

Answer 15

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

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

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

Примеры:

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

C#: save_btn а также newFile_mItem

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

Answer 16

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