Вы называете элементы управления в формах, используя то же соглашение, что и частные переменные?

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

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

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

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

Для этого я бы использовал lblBirthDate для метки, txtBirthDate для текстового поля и calBirthDate для элемента управления календарем.

Однако мне интересно услышать, как это делают другие. :)

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

Hungarian notation or not, I'm more curious if people prepend m_ or _ or whatever they use for standard private member variables.

Люк,

Я использую префикс _ для объектов моей библиотеки классов. Я использую венгерскую нотацию исключительно для пользовательского интерфейса по указанной мной причине.

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

Это кажется более или менее принятым соглашением в сообществе .NET.

Я лично префикс частных объектов с помощью _

Элементы управления формы всегда имеют префикс типа, причина, по которой я делаю это Только, связана с intellisense. С большими формами становится легче «получить значение метки», просто набрав фунт и выбрав его из списка ^ _ ^ Это также следует за логика изложена Джоном Лимджапом.

Хотя это действительно повторяется Руководство Microsoft .NET Coding Guidelines, ознакомьтесь с ними здесь.

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

А вот с элементами управления - совсем другое дело, если говорить о наименовании. Я думаю, что эта область видимости предполагается, и добавление нескольких букв для обозначения типа (например, txtMyGroovyTextbox) имеет больше смысла по той же причине; элементы управления сгруппированы в Intellisense по типу.

Но на работе это полностью VB, а мы делаем mPrivateMember. Я думаю, что m может означать модуль.

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

Я нахожусь в лагере прописных / строчных букв («title» - частное, «Title» - общедоступное), смешанное с «венгерской» нотацией для компонентов пользовательского интерфейса (tbTextbox, lblLabel и т. д.), И я рад, что у нас нет Visual Case-Insensitive-Basic разработчиков в команде :-)

Мне не нравится подчеркивание, потому что оно выглядит некрасиво, но я должен признать, что у него есть преимущество (или недостаток, в зависимости от вашей точки зрения): в отладчике все частные переменные будут наверху из-за того, что _ поверх алфавита. Но опять же, я предпочитаю, чтобы моя пара private / public были вместе, потому что это позволяет упростить отладку логики геттера / сеттера, поскольку вы видите частное и общедоступное свойство рядом друг с другом,

Я прошел через VB и сохранил префикс типа элемента управления для элементов управления. Мои частные члены используют регистр нижнего верблюда (firstLetterLowercase), в то время как открытые члены используют регистр Pascal / верхний регистр (FirstLetterUppercase).

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

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

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