Почему StyleCop рекомендует префиксировать вызовы метода или свойства с помощью «this»?

Question

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

SA1101: вызов {метода или имени свойства} должен начинаться с 'this.' префикс, указывающий, что элемент является членом класса.

С другой стороны, код явно более многословен, так каковы преимущества следования этому правилу? Кто-нибудь здесь следует этому правилу?

Answer 1

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

• существует фактическая неоднозначность - в основном это влияет либо на конструкторов (this.name = name;), либо на вещи типа Equals (return this.id == other.id;)
• вы хотите передать ссылку на текущий экземпляр
• вы хотите вызвать метод расширения для текущего экземпляра

Кроме этого я считаю этот беспорядок. Поэтому я отключаю правило.

Answer 2

Это может сделать код более понятным с первого взгляда. Когда вы используете this, проще:

• Различать статические элементы и элементы экземпляра. (И отличать методы экземпляра от делегатов.)
• Различение элементов экземпляра от локальных переменных и параметров (без использования соглашения об именах).

Answer 3

Я думаю, что эта статья объясняет это немного

http://blogs.msdn.microsoft.com/sourceanalysis/archive/2008/05/25/a-difference-of-style.aspx

... блестящий молодой разработчик в Microsoft (хорошо, это я) решил взять на себя задачу написать небольшой инструмент, который мог бы обнаруживать отклонения от стиля C #, используемого в его команде. StyleCop родился. В течение следующих нескольких лет мы собрали все рекомендации по стилю C #, которые мы могли найти в различных командах Microsoft, и отобрали все лучшие практики, которые были общими для этих стилей. Они сформировали первый набор правил StyleCop. Одним из первых правил, появившихся в результате этих усилий, было использование префикса this для вызова членов класса и удаление префиксов подчеркивания из имен полей. Стиль C # официально развился от его старого племени C ++.

Answer 4

this.This 
this.Does 
this.Not 
this.Add 
this.Clarity 
this.Nor 
this.Does 
this.This 
this.Add 
this.Maintainability 
this.To 
this.Code

Использование «this» при чрезмерном использовании или принудительном требовании к стилю - не более, чем выдумка, используемая под предлогом, что <1% разработчиков действительно не понимают код или то, что они делают, и делает это болезненным для 99%, которые хотят писать легко читаемый и обслуживаемый код. </p>

Как только вы начнете печатать, Intellisence выдаст список содержимого, доступного в области ввода текста «this». нет необходимости выставлять учеников, и если вы не совсем понимаете, что именно вы кодируете, вы сможете легко найти нужный вам предмет.

Даже если вы совершенно невежественны, используйте «это». намекнуть на то, что доступно, но не оставляйте это в коде. Есть также множество дополнений, таких как Resharper, которые помогают внести ясность в область и раскрыть содержимое объектов более эффективно. Лучше научиться использовать предоставленные вам инструменты, чем развить вредную привычку, которую ненавидит большое количество ваших коллег.

Любой разработчик, который по своей сути не понимает области действия статического, локального, классового или глобального содержимого, не должен полагаться на «подсказки» для указания области действия. "этот." хуже, чем венгерская нотация, так как, по крайней мере, венгерская нотация дала представление о типе, на который ссылается переменная, и приносит некоторую пользу. Я предпочел бы видеть «_» или «m», используемые для обозначения членов поля класса, а затем видеть «это». во всем мире.

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

Кодеры растут с опытом, «это». это все равно, что попросить кого-нибудь поставить взрослые тренировочные колеса на велосипеде, потому что это то, что им сначала пришлось использовать, чтобы научиться ездить на велосипеде. И взрослые могут упасть с велосипеда 1 на 1000 раз, когда они сядут на него, но это не является причиной, чтобы заставлять их использовать тренировочные колеса.

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

Answer 5

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

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

2) Интеллисенс. Если вы введете «это». вы получите все специфичные для экземпляра члены и свойства в справке. Это облегчает поиск вещей, особенно если вы поддерживаете чужой код или код, который вы не просматривали в течение нескольких лет. Это также поможет вам избежать ошибок, вызванных неправильным представлением о том, какие переменные и методы объявлены, где и как. Это может помочь вам обнаружить ошибки, которые в противном случае не появлялись бы, пока компилятор не задохнулся в вашем коде.

3) Конечно, вы можете добиться того же эффекта, используя префиксы и другие приемы, но возникает вопрос: зачем изобретать механизм для решения проблемы, когда для этого существует встроенный в язык механизм? поддерживается IDE? Если вы нажмете на клавиши, даже частично, это в конечном итоге также уменьшит частоту ошибок, не вынуждая вас отводить пальцы из исходного положения, чтобы добраться до клавиши подчеркивания.

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

Answer 6

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

Это зависит от вашего стиля. Лично я удаляю this. из кода, так как считаю, что это уменьшает отношение сигнал / шум.

То, что Microsoft использует этот стиль внутри, не означает, что вы должны это делать. StyleCop, похоже, стал внутренним инструментом MS. Я за то, что придерживаюсь соглашений Microsoft относительно общественных вещей, таких как:

• имена типов в PascalCase
• имена параметров указаны в camelCase
• интерфейсы должны начинаться с буквы I
• использовать исключительные имена для перечислений, кроме случаев, когда они [Flags]

... но то, что происходит в частных сферах вашего кода, ну, в общем, личное. Делайте все, на что ваша команда соглашается.

Последовательность также важна. Это уменьшает когнитивную нагрузку при чтении кода, особенно если стиль кода соответствует вашим ожиданиям. Но даже когда имеешь дело с иностранным стилем кодирования, если он непротиворечив, тогда это не займет много времени, чтобы привыкнуть к нему. Используйте такие инструменты, как ReSharper и StyleCop, чтобы обеспечить согласованность там, где вы считаете это важным.

Использование .NET Reflector предполагает, что Microsoft не так уж и хороша в соблюдении стандартов кодирования StyleCop в BCL.

Answer 7

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

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

Answer 8

Кроме того, можно дублировать имена переменных в функции, поэтому использование «this» может сделать его более понятным.

class foo {
  private string aString;

  public void SetString(string aString){
    //this.aString refers to the class field
    //aString refers to the method parameter        
    this.aString = aString; 
  }
}

Answer 9

Я следую этому в основном по intellisense причинам. Это так приятно набирать this. и получать краткий список свойств, методов и т. Д.