ВАЖНОЕ ОБНОВЛЕНИЕ (12 апреля 2016 г.):
Нам стало известно, что внутренний стандарт .NET CoreFX team настаивает на использовании знака подчеркивания , не давая понять, почему. Однако если мы внимательно посмотрим на правило № 3, то станет очевидным, что существует система префиксов _, t_, s_, которая позволяет предположить, почему _ был выбран в первую очередь.
- Мы используем
_camelCase для внутренних и частных полей и используем только для чтения, где это возможно. Префикс полей экземпляра с _, статических полей с s_ и потоковых статических полей с t_. При использовании в статических полях readonly должен идти после static (т.е. static readonly, а не readonly static).
- Мы избегаем
this., за исключением случаев, когда это абсолютно необходимо.
Так что, если вы просто как команда .NET CoreFX, работающая над неким критически важным для производительности многопоточным кодом системного уровня, то НАСТОЯТЕЛЬНО ПРЕДЛАГАЕМ, что вы:
- придерживаются своих стандартов кодирования и
- используйте знак подчеркивания и
- больше не читать этот ответ
В противном случае, пожалуйста, продолжайте читать ...
ОРИГИНАЛЬНЫЙ ОТВЕТ:
Давайте сначала договоримся о том, о чем мы говорим. Вопрос в том, как получить доступ к членам экземпляра из нестатических методов и конструкторов класса / подклассов, если модификаторы видимости позволяют это делать.
Подчеркивание-нотация
- предлагает использовать префикс "_" в именах приватных полей
- также говорится, что вы никогда не должны использовать «это», если это не является абсолютно необходимым
This-нотация
- предполагает, что вы просто всегда используете «это». получить доступ к любому члену экземпляра
Почему эта нотация существует?
Потому что так ты
- отличает параметр от поля, когда они имеют одно и то же имя
- убедитесь, что вы работаете в контексте текущего экземпляра
Пример
public class Demo
{
private String name;
public Demo(String name) {
this.name = name;
}
}
Почему существует знак подчеркивания?
Некоторым людям не нравится вводить «это», но им все еще нужен способ различать поле и параметр, поэтому они согласились использовать «_» перед полем
Пример
public class Demo
{
private String _name;
public Demo(String name) {
_name = name;
}
}
Кто-то может подумать, что это вопрос личного вкуса, и оба способа одинаково хороши / плохи. Однако есть некоторые аспекты, где эта нотация превосходит нотацию подчеркивания:
Ясность
- имена с подчеркиванием в беспорядке
- this-нотация сохраняет имена без изменений
Когнитивная нагрузка
примечание подчеркивания является непоследовательным, оно заставляет вас обращаться с полями особым образом, но вы не можете использовать его с другими членами, каждый раз, когда вам нужно спросить себя, нужно ли вам свойство или поле
эта нотация непротиворечива, вам не нужно думать, вы просто всегда используете "this" для обозначения любого члена
ОБНОВЛЕНИЕ: как было указано, следующее не является преимуществом
Техническое обслуживание
примечание подчеркивания требует, чтобы вы следили за _ во время рефакторинга, скажем, превращение поля в свойство (удалить _) или наоборот (добавьте _)
у этой нотации такой проблемы нет
Автозаполнение
Когда вам нужно увидеть список членов экземпляра:
- Подчеркивание не очень вам помогает, потому что когда вы набираете «_», всплывающее окно автозаполнения показывает вам закрытые поля и все типы, доступные из связанных сборок, смешанных с остальными членами экземпляра
- this-нотация дает вам четкий ответ, набрав «this», все, что вы видите, это список членов и ничего больше
Неоднозначность
Иногда вам приходится иметь дело с кодом без помощи Intellisense. Например, когда вы делаете обзоры кода или просматриваете исходный код онлайн.
примечание подчеркивания неоднозначно: когда вы видите Something.SomethingElse, вы не можете сказать, является ли Something классом, а SomethingElse является его статическим свойством ... или, возможно, Something является текущим свойством экземпляра, у которого есть собственное свойство SomethingElse
эта нотация понятна: когда вы видите Something.SomethingElse, это может означать только класс со статическим свойством, а когда вы видите this.Something.SomethingElse, вы знаете, что Something является членом, а SomethingElse является его свойством
Методы расширения
Вы не можете использовать методы расширений на самом экземпляре, не используя "this".
- примечание подчеркивания требует, чтобы вы не использовали "this", однако с методами расширения вы должны
- эта нотация избавляет вас от колебаний, вы всегда используете "это", точка.
Поддержка Visual Studio
Официальные рекомендации
Существует множество официальных руководств, в которых четко сказано "не используйте подчеркивания", особенно в C #