Соглашение об именовании переменных экземпляра C # .NET?

Question

Я делаю небольшую стажировку в компании, и в их коде я нахожу классы с такими именами:

public class FlagsConfig
{
    private static FlagsConfig _instance; 
}

Является ли _instance соглашением об именовании любого вида в C #?

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

Answer 1

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

Согласно этому документу, все в порядке.

Answer 2

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

private string m_foo;
private static string s_foo;

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

Что важнее - конечно, если вы создаете API и т. Д., Это именованиеобщедоступные члены (включая защищенные и имена параметров). На этом этапе вам следует ознакомиться с руководящими принципами Microsoft .

Answer 3

Является ли _instance соглашением об именах любого вида в C #?

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

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

Однако важно то, что даже для частных деталей реализации вы никогда не должны использовать две подчеркивания. Команда компилятора C # оставляет за собой право создавать любое слово, начинающееся с двух подчеркиваний, чтобы иметь любое значение, которое мы выбираем в какая-то будущая версия языка. Это наш «аварийный люк» на тот случай, если нам действительно нужно действительно добавить новое неконтекстное зарезервированное ключевое слово и действительно, мы действительно не хотим нарушать какой-либо существующий код.

Это описано в разделе 2.4.2 спецификации C # 4.

Answer 4

Да, это общий стандарт именования для частных полей:

http://csharpguidelines.codeplex.com/

Я согласен с @JonSkeet, что подчеркивание грязное, но AFAIK - это стандарт MS. Документ, на который он ссылается, указывает , а не , используя подчеркивания в вашей библиотеке, но я полагаю, что это относится к публичным членам.

Обновление

Первая ссылка фактически защищает противоположное; не используйте подчеркивания. Моя ошибка, но это все еще полезный ресурс.

В знак уважения к г-ну Скиту я перешел по его ссылке далее: http://msdn.microsoft.com/en-us/library/ms229012.aspx, в которой также говорится, что вы не должны использовать подчеркивания, но это руководство относится к статическим, защищенным и открытым членам, но не обязательно частные участники.

Итог : Да, это общий стандарт, но сначала используйте любой согласованный внутри страны стандарт, прежде чем пытаться найти / использовать внешние стандарты.

Answer 5

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

Возможно, лучший вопрос, который нужно задатьВаши разработчики (или высшие руководители), если у них есть какая-либо документация / ссылки на стандарты, которые они используют?

Answer 6

_name грязный, запутанный и очень старый стиль. не делай этого.

.NET 4.0 Общие соглашения об именах http://msdn.microsoft.com/en-us/library/ms229045.aspx

Как видите, MSDN сообщает

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

Answer 7

Это довольно часто встречается в моем опыте. Чтобы помочь определить конкретные виды переменных (рядовые значения, параметры метода и т. Д.), Разработчик может использовать различные условия именования.

, например

• VariableName
• variableName (случай верблюда)
• _variable
• VARIABLE_NAME

Это, как мне кажется, зависит от компании.

Answer 8

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

Private _someValue As Boolean
Protected Property SomeValue() As Boolean
    Get
        Return _someValue
    End Get
    Set(ByVal value As Boolean)
        _someValue = value
    End Set
End Property

Обновление: Кроме того, многие классы в исходном коде .NET используют это соглашение. Особенно в System.Web .

Answer 9

Мне нравится использовать изменение регистра, чтобы различать поля и свойства:

// A private field
private Boolean someValue;
// A public property, exposing my private field
public Boolean SomeValue {
    get { return someValue; }
    set { someValue = value; }
}

Answer 10

Есть два общих соглашения.

первый - «Подчеркивание пользователя как маркер поля» второй «Использовать s_ для статических полей и m_ для интенсивных полей»

ИМХО, это религиозный вопрос, и единственно важно не смешивать оба стиля.

Эта книга содержит много хороших идей о конвенциях и правилах дизайна

http://www.amazon.de/Framework-Design-Guidelines-Conventions-Development/dp/0321545613/ref=sr_1_1?ie=UTF8&qid=1320395003&sr=8-1