it-swarm.com.ru

Лучшие практики для соглашений по именованию C # GUI?

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

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

67
Will Eddins

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

btnUserEmail

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

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

73
Neil N

Я использую:

TextBox nameTextBox;

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

MailAddress homeAddress;

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

string fullName;

Не:

string fullNameString;

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

28
Lee

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

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

12
Christian Hayter

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

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

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

9
Brandon

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

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

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

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

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

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

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

4
zimmer62

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

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

TextBox name

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

3
Andrew Hare

Я использую нотацию Hungation с одним небольшим отличием.

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

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

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

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

MOSU"

3
mosu

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

2
Matt Grande

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

2
ShdNx

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

CString Name;
CEdit ctlName;

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

TextBox ctlName

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

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

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

2
Brad Bruce

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

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

2
Craig

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

TextBox _searchValueTextBox

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

1
terR0Q

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

1
Gabriel Mongeon

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

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

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

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

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

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

1
Rohit.Net

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

1
Cleiton

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

1
Austin Salonen

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

0
Dr Jack