Рекомендации по применению именования C# GUI?

Question

Графические интерфейсы, написанные в 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 обычно файлы, и посмотреть, как другие делают так хорошо, но GUI имеет тенденцию нарушать эти правила или сильно варьироваться. Я не видел никаких рекомендаций Microsoft, которые специально относятся к элементам GUI, а не только к обычным переменным, или даже к примерам, которые применяются за пределами консольного приложения.

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

Answer 1

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

btnUserEmail

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

Answer 2

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

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

TextBox name 

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

Answer 3

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

Answer 4

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

Answer 5

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

CString Name; 
CEdit ctlName; 

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

TextBox ctlName 

Это просто достаточно напоминание о том, что переменная является контроль, а не значение контроля ,

Я думаю, что в том числе и тип, как часть имени, просто СТАРЫЙ.

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

Answer 6

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

Answer 7

Я использую:

TextBox nameTextBox; 

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

MailAddress homeAddress; 

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

string fullName; 

Не:

string fullNameString; 

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

Answer 8

Такое же соглашение, как и все остальное в .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 

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

Answer 9

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

TextBox _searchValueTextBox 

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

Answer 10

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

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

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

Answer 11

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

Answer 12

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

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

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

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

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

Capitalization Styles

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

Answer 13

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

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

Answer 14

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

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

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

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

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

MOSU»

Answer 15

Вы имеете Guidelines for Names от Microsoft. Я не буду следовать за всем, но это хорошая отправная точка.

Answer 16

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

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

1. Intellisense объединяет все те же типы.
2. Форма собственности окна также показать все же контроль отсортирован
3. На сложных форм, которые вы можете легко определить, вы имеете дело с этикеткой или текстового поля (например. LblAccounts и txtAccounts)
4. Новый пользователь может легко справиться с кодировкой.
5. Представьте, что у меня есть учетная запись Lst, accountlbl, accounttxt, accountgrd, accountChk на той же форме.

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

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

Выбор за вами, какой вы хотите!

Answer 17

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