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

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

TextBox _searchValueTextBox

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

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

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

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

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

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

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

TextBox name

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

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

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

Я предпочитаю венгерскую нотацию, так как все мои элементы управления UI отображаются в одном блоке в Intelisense. UX для «Пользовательского опыта». Также хорошо, если вы измените элемент управления с текстового поля на поле со списком или что-то в этом роде, поскольку имя не изменится.

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

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

Я использую:

TextBox nameTextBox;

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

MailAddress homeAddress;

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

string fullName;

Not:

string fullNameString;

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

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

CString Name;
CEdit ctlName;

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

TextBox ctlName

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

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

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

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

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

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

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

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

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

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

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

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

I use the Hungation notation with one little difference.

I now work on a project that has quite a rich UI. So finding, with Intellisense, a button called, let's say, btnGetUsers its very easy.

Things get's complicated when the application is able to get users from different locations. That is different controls. So I started to name my controls after where they are located and still use the Hungarian notation.

As an example: tabSchedAddSchedTxbAdress means that txbAddress is a text box where an address can be inserted and is located on the Add Scheduling tab from the Scheduling Tab Control. This way I can find controls very easy and, when I type simply "btn" I don't get, at once, a lot of buttons from all over the user interface.

Of course this is just to help myself. I'm not aware of such a best practice. However it helps a lot.

Mosu'

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