Каков общепринятый способ обращения к свойствам членов внутри класса в C#?

Прежде всего - для простых случаев получения / установки я бы рекомендовал вам использовать автоматически реализуемые свойства. Если вы это сделаете, компилятор сгенерирует базовую переменную, а вы будете ссылаться только на само свойство.

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

Самый распространенный из них, который я видел в примере кода, - это простой префикс _.

Однако что действительно важно, так это то, что команда согласна с тем, что такое стандарт, и придерживается его.

Я думаю, что какое бы соглашение об именах вы ни использовали, самое главное - оставаться последовательным. Я имею в виду, что если вы решите называть частные члены, например, _name, то всегда делайте это так, вместо того, чтобы один раз использовать _name, а в другой раз - m_name. Я лично использую соглашение о префиксе подчеркивания. (одна из причин заключается в том, что я использую NHibernate, а NHibernate имеет стратегию доступа field.camelcase-underscore.

По вашему другому вопросу: Это зависит от того, чем вы хотите заниматься. Содержит ли ваша собственность дополнительную логику, и хотите ли вы, чтобы эта логика выполнялась, когда вы на нее ссылаетесь? Тогда воспользуйтесь собственностью. Вы не хотите выполнять логику? Используйте поле. Эрик Липперт написал об этом Почта в своем блоге.

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

Если вы не можете использовать автоматически реализуемое свойство, как предлагает Брайан Расмуссен, и у вас должен быть частный член, я бы рекомендовал использовать префикс подчеркивания _name.

В intellisense не сразу очевидно, является ли элемент параметром, локальным или частным членом, поскольку все они имеют один и тот же символ (синий куб). Однако, если вы переместите курсор на конкретный элемент, всплывающая подсказка сообщит вам, что это за элемент.

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

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

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

Лично я использую префикс подчеркивания, поскольку считаю, что он дает мне хорошую визуальную подсказку.

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

Я работал над кодом, который требовал руководства только для чтения ... «m» означало уровень класса, «p» означало параметр и т. д. Соглашение об именах было разработано, чтобы упростить чтение кода, но в итоге оно просто наоборот, потому что разработчики исходили из того, что «хорошие» соглашения об именах означают читаемый код.

Просто убедитесь, что эта цитата Денниса Грина (бывшего тренера Arizona Cardinal) применима к вашим идентификаторам: «Они такие, какими мы их считали!»

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

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

Раньше я был категорически против префикса «_», но он действительно полезен с intellisense, когда вы хотите быстро получить доступ к полю члена, не набирая много букв.

Для переменных уровня класса наши стандарты кодирования говорят, что используйте mVariableName или m_VariableName. Главное - следить за своей компанией / учителями / и т. д. стандарты / практики кодирования.

Я лично обращаюсь к переменной только через ее геттер / сеттер, если он есть. Даже если переменная используется только внутри класса, я использую автоматические свойства. Таким образом, я добавляю уровень абстракции, что означает меньше кода для рефакторинга, если я что-то изменил.

Кстати, ваша функция void не может возвращать строку ..... :-)

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

Хотя вокруг использования Style Cop ведутся большие дискуссии, я бы предложил одну вещь: если вы используете Style Cop, то оставьте все стили включенными. Таким образом, когда вы делитесь между пользователями, это значительно упрощает работу.

Одна из вещей, которые это усугубляет, заключается в том, что вы не можете называть свои личные поля символами подчеркивания. Поэтому я обычно использую camelCase при написании частных полей, а затем PascalCase для общедоступных свойств:

private string name;
public string Name
{
    get { return this.name; }
    set { this.name = value; }
}

Style Cop также требует использования this., что значительно упрощает чтение.

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

Прежде всего, я и многие другие, с которыми я работал, отказались от использования префикса для закрытых членов с помощью «m_». Затем, когда я обращаюсь к частному члену внутри класса, я обычно использую слово this как в "this.privateMemberVariableName". Этого достаточно, чтобы различить, что переменная не является локальной переменной или переменной, переданной в качестве параметра в методе.

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

каркас Книга руководящих принципов дизайна говорит, что вы не должны префикс своих переменных с помощью _ - вы должны просто использовать нижний регистр для имени переменной, а Code Complete 2nd edition, как я полагаю, говорит, что вы не должны префикс ваших переменных с помощью m_.