Рекомендации для соглашений об именовании графического интерфейса C#? [закрытый]

Я использую:

TextBox nameTextBox;

как использовать:

MailAddress homeAddress;

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

string fullName;

нет:

string fullNameString;

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

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

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

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

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

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

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

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

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

TextBox name

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

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

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

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

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

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

Стили Капитализации

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

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

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

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

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

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

Mosu'

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

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

CString Name;
CEdit ctlName;

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

TextBox ctlName

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

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

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

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

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

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

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

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

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

TextBox _searchValueTextBox

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

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

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

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

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

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

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

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

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