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


18

Я задал этот вопрос довольно давно: как вы называете свои личные переменные в C #?

В одном из ответов я указал на страницу MSDN от Microsoft, которая показывает, что частные переменные / поля должны быть названы так:

private int myInteger;

Но параметр будет:

void SomeMethod(int myInteger)

и локальная переменная будет выглядеть так:

int myInteger;

Поэтому, когда вы ссылаетесь на них, как это

myInteger = 10;

у вас нет возможности узнать, о ком вы говорите.

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

Мне интересно то же самое. Почему стандарт Microsoft не отличает их?


10
Что вы имеете в виду "у вас нет возможности узнать, о ком вы говорите"? Конечно ты делаешь - размах.
Томас Оуэнс

2
Это руководство кажется устаревшим, по-умолчанию, более резкое уточнение (которое стало чем-то вроде руководства по стилю defacto) рекомендует ставить префикс частных полей с подчеркиванием, что я всегда делал в любом случае.

25
@kekekela: Это абсолютно не устарело; StyleCop явно помечает любые экземпляры переменных-членов, начинающиеся с подчеркивания. Честно говоря, я нахожу подчеркивание бессмысленным и раздражающим, потому что корпус передает точно такую ​​же информацию. Если вам нужно сделать область видимости явной, то присвойте префикс с помощью this..
Ааронаут

12
@Aaronaught Я нахожу кучу лишних "это". разбросаны по моему коду бессмысленно и раздражающе.

12
@kekekela: Единственное место, где я когда-либо сталкиваюсь с этим, - это конструктор, и в конструкторе это имеет смысл, потому что вы буквально передаете значения, которые инициализируют поля-члены ( this.component = component). Если вы обнаружите, что у вас есть неоднозначные возможности в других местах, такие, что у вас есть «куча избыточных» это. разбросаны вокруг вашего кода ", то у вас есть плохо написанный код.
Ааронаут

Ответы:


14

Изначальные соглашения об именах имели префикс m_ для учеников, это было сокращено до простого подчеркивания. Вы увидите много старого кода C # Microsoft, используя префикс подчеркивания. Тем не менее, однажды я услышал в Tech Ed, что ведущие подчеркивания не соответствуют CLS. Я полагаю, что именно по этой причине они перешли на более простую схему «одно имя подходит всем». Раньше (не уверен сейчас), что имена VB.Net без учета регистра также не были совместимы с CLS.

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

Вам не нужно делать все, что MS говорит вам делать.


1
Я думаю, что вы перепутали "CLR-совместимый" с "CLS-совместимым". Если что-то не соответствует CLR, оно не скомпилируется. CLS - это всего лишь предупреждение о том, что он может быть несовместим с другими языками и в основном затрагивает только общедоступные элементы (технически вещи, видимые за пределами вашей сборки).
Джоэл С

@ Джоэл - Ты прав. Этот вопрос имеет дело с этим: stackoverflow.com/questions/1195030/…
Дейв

2
Я до сих пор использую префикс "m_" ...
CesarGon

4
+1 «для вас не нужно делать все, что MS говорит вам делать». Думайте сами!
gbjbaanb

1
Это только не CLS-Соответствует, если поле protectedне,private
Rachel

9

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

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

Википедия утверждает, что в C и C ++

Имена, начинающиеся с двойного подчеркивания или подчеркивания и заглавной буквы, зарезервированы для реализации (компилятор, стандартная библиотека) и не должны использоваться (например, __reserved или _Reserved).

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


2
Приятное замечание о параметрах и локальных переменных, имеющих одинаковую область видимости (+1). Никто другой не упомянул это. Следствием этого является то, что если вам нужна локальная переменная с тем же именем, что и у параметра, вы можете просто использовать этот параметр. Лично я нахожу подчеркивание уродливым и неточным. Принимая во внимание, что thisопределенно относится к текущему объекту. Я не понимаю ненависть к this. Это потому, что это неправильно понято?
Джейсон С

4

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

Многие люди создают свои собственные соглашения, добавляя префикс переменных экземпляра с помощью _или m_, но я действительно не думаю, что это имеет значение. Вы можете многое сделать из контекста, и IDE в наши дни достаточно умны, чтобы помочь вам. Например, Visual Studio с надстройкой ReSharper покажет вам локальные переменные и переменные экземпляра в разных цветах.

Если действительно важно различать две области, вы можете использовать this.префикс для ссылки на переменную экземпляра:

public class Test
{
    private int myInteger;

    void SomeMethod(int myInteger)
    {
        this.myInteger = 10; // sets instance variable to 10
        myInteger = 10; // does not affect the instance variable.
    }
}

Без других плагинов Visual Studio по умолчанию поможет вам с Intellisense:

Скриншот

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

Вы также можете использовать инструменты анализа кода, такие как FxCop и StyleCop, чтобы помочь вам выявить потенциальные проблемы с именами переменных и областью видимости.


Чтобы уточнить немного this, я всегда предпочитаю this, потому что это определенно относится к текущему экземпляру, в каком бы доме вы ни находились, так что это точно. Условные обозначения подчеркивания или подчеркивания - это просто условные обозначения, которые могут или не могут ссылаться на переменные экземпляра, и они становятся избыточными this. Единственное место, которое я считаю полезным подчеркнуть, - это нечувствительный к регистру VB для различения имен объектов и классов. Но это совсем другая история.
Джейсон С

4

Почему стандарт Microsoft не отличает их?

Люди из Microsoft написали книгу под названием Framework Design Guidelines, в которой объясняется ряд соглашений, в том числе, почему некоторые вещи были в верблюжьей , а другие - в паскалях .

Изменить (добавив детали из книги):

В книге они упоминают, что изучают юзабилити, а также некоторые уроки, извлеченные из приобретения группы Turbo Pascal. Кроме того, хотя не все языки чувствительны к регистру (например, VB), другие (например, C #) должны быть согласованы с именами. Нельзя полагаться на различия в одном только случае, чтобы различать предметы. Если придерживаться соглашений, используемых остальной частью структуры, это приведет к меньшей путанице со стороны разработчиков.

Глава 3, Правила именования.
Раздел 3.1 - это соглашения о капитализации.

camelCasingдля имен параметров.
PascalCasingдля пространства имен, типа и имен членов. Если в названии есть двухбуквенные аббревиатуры, держите их заглавными, например IOStream.

Раздел 3.5 посвящен именам классов, структур и интерфейсов.
Раздел 3.6 посвящен именованию членов типа.
Раздел 3.7 описывает параметры именования.


4
Не могли бы вы подвести итог для тех из нас, кто не владеет книгой?
Kramii восстановит Монику

Я согласен с Крамием. Резюме было бы здорово!
Ваккано

@Kramil, Vaccano, похоже, мне придется еще раз проверить это из библиотеки. Обычно я делаю это только тогда, когда начинаю новую работу, и обсуждения переходят к стандартам именования и кодирования.
Tangurena

1
LOL, поэтому «Нельзя полагаться на различия в одном только случае для различения предметов», а затем продолжает использовать camelCase или PascalCase для различения предметов.
gbjbaanb

1

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

Например, вы когда-нибудь использовали параметр в качестве переменной-члена? Или локальная переменная в качестве параметра? Как насчет членской переменной как локальной?

  • Все переменные-члены находятся в «теле» класса. Я действительно не покупаю аргумент, что вам нужно использовать префикс члена, когда вы можете использовать его, thisчтобы отличить его от локальной переменной с похожим именем, иначе это не нужно.

  • Локальная переменная также определяется только в области видимости метода или в области блока кода.

  • Параметр всегда определяется в сигнатуре метода.

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


0

Я не могу ответить на ваш вопрос о стандартах Microsoft. Если вы хотите стандартные различать эти вещи, стандартное использование I параметров PL / SQL является префикс имени параметра с in_, out_, io_, для входов, амбулаторных, так и в-out- параметров. Переменные, которые являются локальными для функции, имеют префикс v_.


0

Большинство известных мне компаний имеют стандарты кодирования, в которых в качестве префикса для переменных-членов указывается либо буква подчеркивания, либо строчная буква m (для «члена»).

Так

_varName

или

mVarName


2
Да, но MS не одобряет использование m для участников, к чему стремится OP.
Кристофер Биббс

«Большинство компаний» не включает Microsoft, которая является компанией, о которой этот вопрос.
Ааронаут

1
Я не понимал, что Micrsoft MSDN для внутренних стандартов кодирования в Microsoft.
JeffO


0

Как и указывали другие люди, вы обычно можете определить, какой является, по какой области используется элемент. Вы на самом деле не можете иметь параметр и локальную переменную в одной и той же области видимости, и если вам нужна закрытая переменная, просто используйте this.myInteger. Поэтому я не думаю, что Microsoft беспокоится об этом слишком сильно, так как вы можете легко различать их, если хотите.

Но, как говорится, я немного удивлен, что никто еще не сказал об этом, но забудьте о Microsoft и их соглашениях об именах (ну, кто-то, возможно, уже сказал это, так как мне пришлось бежать на собрание и оставить это открытым, не представляя Это). Венгерская нотация была также соглашением об именах, начатым в Microsoft (или это был Xerox? Я никогда не могу вспомнить, когда придумал Simonyi). Я не могу думать ни о ком, кого я знаю, который не проклинает название венгерской нотации по сей день. Мы были настолько раздражены этим в том месте, где я работал, что придумали наш собственный стандарт, который мы использовали внутри. Это имело больше смысла для нас и немного ускорило нашу работу (на самом деле это было довольно близко к тому, что сейчас предлагает Microsoft, но все было в паскале, за исключением частных переменных).

Тем не менее, новый стандарт, который использует Microsoft (сочетание верблюжьего и паскальского дела), не так уж и плох. Но если вам и вашим коллегам это не нравится, придумайте свой собственный набор стандартов (коллективно лучше). Это, конечно, зависит от того, есть ли в вашей компании набор стандартов. Если они это сделают, придерживайтесь их. В противном случае придумайте, что работает для вас и ваших коллег. Просто держи это логично.

Поскольку Аарона попросил процитировать Чарльза Симони и венгерскую нотацию: http://en.wikipedia.org/wiki/Charles_Simonyi

http://en.wikipedia.org/wiki/Hungarian_notation

http://msdn.microsoft.com/en-us/library/aa260976(v=VS.60).aspx

http://ootips.org/hungarian-notation.html

http://www.hitmill.com/programming/vb/Hungarian.html

http://web.mst.edu/~cpp/common/hungarian.html

Последние два являются лишь примерами венгерской нотации, а ссылка на ootips - всего лишь несколько цитат, касающихся некоторых мнений по этому вопросу. Обратите внимание, что существует также система венгерской нотации, но, насколько я знаю, она стала популярной среди программистов Microsoft (хотя, в отличие от Simonyi для вариаций приложений, я не знаю кого).


1
1) венгерский язык не был изобретен Microsoft, и 2) «венгерский», на который вы ссылаетесь, - это тип венгерский, а не семантический венгерский.
Ааронаут

Я никогда не говорил, что Microsoft придумала это. Я на самом деле сказал, что Чарльз Симони придумал это (особенно приложения венгерской нотации). Microsoft настаивала на этом сильно, но я никогда не говорил, что они его создали (на самом деле я сказал, что не уверен, создал ли он его во времена Xerox или Microsoft). Я привел это в качестве примера того, что крупная компания (Microsoft) предложила, как все должно быть сделано. Моя точка зрения во всем этом заключается в том, что ОП не должен беспокоиться о соглашениях по присвоению имен, которые компания, на которую он не работает, говорит, что это «правильный путь» (если он не работает на Microsoft, в этом случае его это должно волновать).
Джекрейг

[нужная цитата]
Aaronaught

1
Хм, да, нам не нужна была цитата о том, что такое венгерская нотация. [Необходимая цитата] относится ко всем сомнительным утверждениям в вашем ответе.
Aaronaught
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.