textBoxEmployeeName по сравнению с employeeNameTextBox

Я обнаружил, что в функции clf.train я изменяю массив training своей конструкцией, так как массив передается по ссылке. Вот почему модель плохо показала результаты оценки сразу после обучения, так как в ней были эффективные технические характеристики, основанные на инженерных функциях. Перезагрузка данных тренировки перед оценкой устранила проблему.

13
задан 4 revs, 3 users 100% 14 January 2009 в 13:59
поделиться

14 ответов

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

8
ответ дан 1 December 2019 в 21:53
поделиться

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

0
ответ дан 1 December 2019 в 21:53
поделиться

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

0
ответ дан 1 December 2019 в 21:53
поделиться

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

K

1
ответ дан 1 December 2019 в 21:53
поделиться

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

0
ответ дан 1 December 2019 в 21:53
поделиться

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

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

    public Name EmployeeName { get; set; }
    
  2. Чтобы получить или установить EmployeeName, Ваш код с сохранением информации должен явно назвать метод. Сделайте это этот путь, потому что это предполагает, что состояние не хранится на представлении, но может быть получено из или транспонировано к представлению:

    public void SetEmployeeName(Name employeeName);
    public Name GetEmployeeName();
    
  3. Венгерская запись глупа. Это было полезно на языках <= VB6, потому что они использовали позднее связывание тип переменных. Необходимо было защитить себя, потому что несоответствия типов были ошибками периода выполнения, не время компиляции. Только используйте txtEmployeeName если Вы также использовали бы strEmployeeName и intEmployeeNumber.

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

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

4
ответ дан 1 December 2019 в 21:53
поделиться

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

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

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

0
ответ дан 1 December 2019 в 21:53
поделиться

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

txtEmployeeName;
lblEmployeeName;
2
ответ дан 1 December 2019 в 21:53
поделиться

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

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

3
ответ дан 1 December 2019 в 21:53
поделиться

Когда я считал его, статья, связанная с в статье, упомянутой в вопросе (а именно, Названия Ресурсов), действительно использует тип управления в конце, в FileMenuArgumentException хотя это не управление).

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

1
ответ дан 1 December 2019 в 21:53
поделиться

НЕОБХОДИМОСТЬ ЧТЕНИЕ является Инструкциями XAML, выпущенными Jaime:

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

1
ответ дан 1 December 2019 в 21:53
поделиться

Идеи:

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

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

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

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

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

0
ответ дан 1 December 2019 в 21:53
поделиться

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

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

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

1
ответ дан 1 December 2019 в 21:53
поделиться

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

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

Похожие вопросы: