Всегда ли префиксация (авто)свойств с помощью ключевого слова this-считается хорошей практикой?
С тех пор как я узнал о свойствах автомобилей, я стараюсь использовать их везде. Раньше для каждой собственности, которую я имел, всегда был частный член, который я использовал бы внутри класса. Теперь это свойство заменено свойством auto. Я использую свойство внутри своего класса так, как обычно использую обычное поле члена. Проблема в том, что свойство начинается с Капитолия, что делает его немного странным imho при использовании его таким образом. Я не возражал, что недвижимость начинается с Капитолия раньше, потому что они всегда будут за "точкой". Теперь я обнаружил, что префиксую все свойства, которые я использую внутренне с this.
, чтобы успокоить мое чувство.
Моя дилемма заключается в том, что раньше я всегда был немного против префиксов всех внутренних членов с this.
, если только это не "необходимо" (как в сеттере или конструкторе). Поэтому я как бы ищу второе мнение по этому поводу. Есть ли стандартный хороший способ сделать это? Должен ли я просто перестать жаловаться (у меня есть тенденция быть " муравьиным горбом" (Голландское выражение))?
До:
class Foo
{
private Bar bar;
public Bar Bar { get { return bar; } }
public Foo(Bar bar)
{
this.bar = bar;
}
public void DoStuff()
{
if(bar != null)
{
bar.DoMethod();
}
}
}
После:
class Foo
{
public Bar Bar {get; private set;}
public Foo(Bar bar)
{
this.Bar = bar;
// or
Bar = bar;
}
public void DoStuff()
{
if(this.Bar != null)
{
this.Bar.DoMethod();
}
// or
if(Bar != null)
{
Bar.DoMethod();
}
}
}
Обновление
Похоже, что мнения расходятся, хотя все больше людей выступают за приставку с this.
. До появления свойств auto я всегда был в значительной степени против префиксов с this.
вместо конструкторов и сеттеров (как я уже упоминал ранее). Но теперь я просто больше ничего не знаю.
Дополнительное Примечание: тот факт, что свойство также часто называют тем же, что и класс (public Bar Bar { get; private set; }
), также заставляет меня склоняться к приставкам. Каждый раз, когда я набираю Bar.DoMethod()
, я чувствую, что это похоже на статический метод. Несмотря на то, что VS будет окрашивать Bar
, если это статический метод, и у вас не может быть статического метода и метода экземпляра с одной и той же сигнатурой. Когда он окрашен, ясно, что это статический метод, но когда он не окрашен, не на 100% ясно, что это не статический метод. Например, вы можете просто пропустить утверждение using
, но также и потому, что я не привык связывать не-бытие цвет зависит от того, статический это вызов или нет. Раньше я бы сразу увидел его по заглавной букве первой буквы в случае члена или по " точке "в случае свойства (например," точка " после foo
в (Foo)foo.Bar.DoMethod()
).
(на данный момент трудно выбрать "приемлемый ответ")
4 ответа:
Да, есть "стандартный способ сделать это": заглавная буква и префикс this считаются хорошей практикой кодирования. Если вы используете какой-либо инструмент для проверки кода на соответствие рекомендациям по кодированию, например ReSharper или собственный Microsoft StyleCop, он предупредит вас, если вы не используете эту ссылку или не начинаете свои свойства с большой буквы.
Ваши свойства публично видны. Любая общественная собственность, поле или метод должны начинаться с капитала.
Любое свойство, поле или метод, который вы вызываете внутри вашего собственного класса, который является частью этого класса, должны иметь префикс this-reference для удобства чтения.
Update : конечно, мнения разнятся. Мне нравится нажимать
this.
, а затем, после точки, видеть только члены, вместо того, чтобы видеть все ключевые слова, когда просто нажимаешь ctrl-пробел без префикса. Это мне помогает. Но, в конце концов (цитата отсюда):каково бы ни было ваше мнение, главное дело в том, что всем людям тесно при совместной работе над проектом используйте те же стандарты форматирования, независимо от того, какие эти стандарты являются.
Еще ссылки:
Microsoft по использованию заглавной буквы практически в любом имени и в свойствах в частности.
Большерекомендаций здесь .
Я настоятельно рекомендую использовать ' это. " там, где это возможно. руководящие принципы разработки рамок рекомендует эту практику. Он позволяет узнать область действия с точки зрения читаемости и помогает избежать глупых ошибок, о которых компилятор может сообщить во время компиляции.
И я настоятельно рекомендую Никогда Использование этого, как это только когда-либо уменьшает ясность. Если вы действительно окажетесь в ситуации, когда вам это необходимо, чтобы избежать конфликтов, я бы рекомендовал переименовать одно из полей / свойств / переменных.
Единственное место, где я нахожу это приемлемым, - это если это часть публично открытого API, где переименование вызовет разрушительные изменения.
В первом примере параметр
bar
лексически затеняет полеbar
из экземпляра. Поэтому вы должны использоватьthis
для устранения неоднозначности.Во 2-м примере у вас нет такой двусмысленности, а значит, и не нужна двусмысленность (т. е.
this
). Однако вы все еще можете префиксировать его, если это ваша чашка чая. :)