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

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

public class FlagsConfig
{
    private static FlagsConfig _instance; 
}

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

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

Ответы

Ответ 1

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

В соответствии с этим документом это нормально.

Ответ 2

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

private string m_foo;
private static string s_foo;

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

http://csharpguidelines.codeplex.com/

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

Обновление

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

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

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

Ответ 5

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

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

Ответ 6

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

например.

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

Как правило, это зависит от компании.

Ответ 7

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

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

как вы можете видеть, состояния MSDN

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

Ответ 8

Мне нравится использовать изменение case для различения полей и свойств:

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

Ответ 9

Являются ли ваши сотрудники бывшими разработчиками 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.

Ответ 10

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

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

imo это религиозный вопрос, и только важная вещь - не смешивать оба стиля.

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

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

Ответ 11

В соответствии с StyleCop [Инструмент проверки стилей/конвенций Microsoft) это не должно быть сделано. См.: http://stylecop.soyuz5.com/SA1309.html

Кроме того, вопрос - возможный обман Чтобы подчеркнуть или не подчеркнуть, это вопрос

Ответ 12

Существует много соглашений об именах, которые люди следуют

myFirstVar = Camel Notation

Объявление для верблюдов обычно используется для общедоступных переменных (а не для частных переменных).

MyFirstVar = Pascal Notation

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

str_MyFirstVar = Hungarian Notation // if variable is of type string

Венгерская нотация считается самой старой, но не используется больше.

_myFirstVariable = used for private fields in general