Лучшие практики для соглашений об именах графических интерфейсов С#?

Графические интерфейсы, написанные в WinForms или XAML, по-видимому, имеют самые разные соглашения об именах между проектами, которые я вижу. Для простого TextBox для имени человека я видел различные соглашения об именах:

TextBox tbName      // Hungarian notation
TextBox txtName     // Alternative Hungarian
TextBox NameTextBox // Not even camelCase
TextBox nameTextBox // Field after field with TextBox on the end
TextBox TextBoxName // Suggested in an answer...
TextBox textBoxName // Suggested in an answer...
TextBox uxName      // Suggested in an answer...
TextBox name        // Deceptive since you need name.Text to get the real value
TextBox textBox1    // Default name, as bad as you can get

Я соблюдаю правила StyleCop для всех моих файлов .cs обычно и вижу, что другие делают это тоже, но графический интерфейс имеет тенденцию нарушать эти правила или сильно варьироваться. Я не видел никаких рекомендаций Microsoft, которые специально относятся к элементам GUI, а не только к обычным переменным, или даже к примерам, которые применяются за пределами консольного приложения.

Каковы наилучшие методы для именования элементов в графическом интерфейсе?

Ответ 1

Я использую старую школу венгерский... txt для TextBox, btn для Button, за которым следует обобщенное слово, а затем более конкретное слово. то есть:

btnUserEmail

Многие люди говорили что-то вроде "Боже мой, VB6 звонит!" Но в приложении пользовательского интерфейса Rich winforms я могу находить и изменять вещи быстрее, потому что обычно первое, что вы знаете о элементе управления, это его тип, затем его категория, а затем конкретизируйте. В то время как новый стиль именования парни застряли, пытаясь вспомнить, как они назвали это текстовое поле.

Оригинальная спецификация для элементов управления находится здесь (в архиве).

Ответ 2

Я использую:

TextBox nameTextBox;

Так же, как я бы использовал:

MailAddress homeAddress;

Причиной этого является то, что в этих случаях "TextBox" и "Address" описывают, что представляет объект, а не как он хранится или используется. Но в другом случае, например, при сохранении полного имени человека, я бы использовал:

string fullName;

Не:

string fullNameString;

Потому что "String" не описывает, что представляет объект, а только то, как он хранится.

Ответ 3

Такое же соглашение, как и все остальное в .NET: только описательное имя для верблюда, необязательно сопровождаемое суффиксом, если вам нужно различать разные классы для одной и той же логической "вещи". Например:

string name; // a name
TextBox nameText; // the control used to edit the name
Label nameLabel; // the control used to label the edit control
List<string> nameList; // a list of names

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

Ответ 4

Это не мое изобретение, но мне оно нравится:

TextBox uxName = new TextBox();
Label uxNameLabel = new Label();
Button uxAccept = new Button();

Я предпочитаю это венгерской нотации, так как все элементы моего интерфейса отображаются в одном блоке в intelisense. UX для "User eXperience". Также приятно, если вы измените элемент управления из текстового поля на поле со списком или что-то еще, так как имя не изменится.

Ответ 5

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

Что касается использования конвенции, я бы проголосовал за это:

TextBox name

Он короткий и имеет семантическое значение как идентификатор. Что касается типа идентификатора, я бы полагался на Visual Studio, чтобы сказать вам, что, как правило, он хорош в этом.

Ответ 6

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

Я вижу некоторые довольно ужасные вещи с txtName, NameTextBox, name и textBox1, которые все используются в одной форме... yuck.

Где я работаю, у нас есть документ стандартов, который рассказывает нам, как это сделать, где это сделать, и я думаю, что только 20% людей даже стараются соответствовать и соответствовать.

Я обычно что-то изменю, если Fxcop кричит на меня.

http://en.wikipedia.org/wiki/Naming_conventions_%28programming%29

Стили заглавных букв

Обратите внимание, что: Для большинства идентификаторов Microsoft.NET рекомендует UpperCamelCase (он же "Pascal Style" ). (для параметров рекомендуется использовать lowerCamelCase).

Ответ 7

Я использую нотацию с одной маленькой разницей.

Теперь я работаю над проектом с довольно богатым пользовательским интерфейсом. Поэтому поиск с помощью Intellisense кнопки, называемой, скажем, btnGetUsers, очень просто.

Все становится сложнее, когда приложение может получать пользователей из разных мест. Это разные элементы управления. Поэтому я начал называть свои элементы управления после того, где они находятся, и по-прежнему использовать венгерскую нотацию.

В качестве примера: tabSchedAddSchedTxbAdress означает, что txbAddress - это текстовое поле, в котором адрес может быть вставлен и находится на вкладке "Добавить расписание" из элемента управления вкладками планирования. Таким образом, я могу легко найти элементы управления, и, когда я набираю просто "btn", я не получаю сразу несколько кнопок со всего интерфейса.

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

MOSU

Ответ 8

Я называю все элементы пользовательского интерфейса TypeDescriptor. Следуя вашему примеру, TextBoxName.

Ответ 9

В последнее время я работаю с командой, которая переезжает из MFC (6.0...). Там у них будет что-то вроде

CString Name;
CEdit ctlName;

Самый простой способ миграции - использовать что-то вроде

TextBox ctlName

Это просто напоминание о том, что переменная является элементом управления, а не значением элемента управления.

Я думаю, что в том числе этот тип, как часть имени, просто OLD.

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

Ответ 10

Я использую c_typeName (обратите внимание, что тип и имя разные), например. c_tbUserEmail для TextBox, в который пользователь должен ввести свой электронный адрес. Я нахожу это полезным, потому что, когда есть много элементов управления, их трудно найти в списке длинной intellisense, поэтому, добавив префикс c_, я могу легко увидеть все элементы управления в этой форме.

Ответ 11

Это безумие венгерского/VB6-именования необходимо остановить.

Если Microsoft действительно хотела, чтобы вы написали свои элементы управления на основе их типа, то почему Visual Studio не будет автоматически ссылаться на "txt" или "btn", когда вы добавите элемент управления в свою веб-форму или форму?

Ответ 12

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

Ответ 13

Для элементов, которые я не планирую использовать в своем коде, я просто позволяю дизайнеру обрабатывать его для меня; если они становятся чем-то, что используется в моем коде, они меняются на что-то значимое, и это бывает descriptionType (nameTextBox). Это то, как дизайнер создает их, если им достаточно информации (проверьте пункты меню - "Выход" становится exitMenuItem).

Ответ 14

Моя собственная практика: Тип _contextDescriptionType. Например:.

TextBox _searchValueTextBox

В любом случае соглашение об именовании либо слишком личное, либо навязывается общими правилами. В любом случае он должен быть документирован где-то, чтобы все разработчики проекта могли легко получить доступ.

Ответ 15

У вас есть Руководство для имен от Microsoft. Я не буду следовать за всем, но это хорошая отправная точка

Ответ 16

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

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

Intellisense объединяет все те же типы.
В окне свойств формы также будет отображаться все одинаковое упорядоченное управление
В сложных формах вы можете легко идентифицировать, что вы имеете дело с меткой или текстовым полем (например, lblAccounts и txtAccounts).
Новый пользователь может легко справиться с кодированием.
Представьте, что у меня есть accountLst, accountlbl, accounttxt, accountgrd, accountChk элементы управления в той же форме.

При кодировании разработчик всегда знает, что он обращается к текстовому полю или метке. Где он не понимает, с каким именем пользовался другой разработчик. Поэтому, просто написав "lbl", intellisens выведет список всех лейблов, где есть, если вы использовали подход, использованный в # 5, тогда intellisense будет использовать все элементы управления, используя acc. Я редко видел, что некоторые петли с именем управления начинаются с "учетной записи" или так. Это означает, что это не поможет ни в одном редком случае.

Моя ставка заключается в том, чтобы делать вещи, которые помогают легко понять код для другого разработчика. Потому что, когда вы вырастут в вашем перевозчике, вы не всегда будете кодировать, кто-то другой придет и займет ваше место.

Выбор - ваш, который вам нужен!

Ответ 17

Если в дизайне приложения есть хорошее разделение проблем, я думаю, что нет необходимости указывать кнопки ввода, такие как LoginButton, LoginBtn или btnLogin. Если владелец объекта является элементом пользовательского интерфейса, позвольте ему позвонить ему и если владелец не является элементом пользовательского интерфейса, то объект находится в неправильном месте.