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

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

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

private int myInteger;

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

void SomeMethod(int myInteger)

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

int myInteger;

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

myInteger = 10;

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

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

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

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

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

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

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

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

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

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

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

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

Многие люди создают свои собственные соглашения, добавляя префикс переменных экземпляра с помощью _или 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, чтобы помочь вам выявить потенциальные проблемы с именами переменных и областью видимости.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так

_varName

или

mVarName

Как и указывали другие люди, вы обычно можете определить, какой является, по какой области используется элемент. Вы на самом деле не можете иметь параметр и локальную переменную в одной и той же области видимости, и если вам нужна закрытая переменная, просто используйте 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 для вариаций приложений, я не знаю кого).