Какова текущая лучшая практика в отношении ключевого слова "this" перед полем и методами в c #?

Если нет необходимости проводить различие между переменной и полем с одинаковым именем, я никогда не ставлю this.перед полем или любым доступом к элементу в C #. Я вижу, что это ничем не отличается от m_префикса, который был распространен в C ++, и думаю, что если вам действительно нужно указать, что это член, ваш класс слишком велик.

Однако в моем офисе есть ряд людей, которые категорически не согласны.

Что считается текущей лучшей практикой в ​​отношении this.?

РЕДАКТИРОВАТЬ: Чтобы уточнить, я никогда не использую m_и использую только this.тогда, когда это абсолютно необходимо.

В соответствии с руководящими принципами проектирования , при обращении к открытым или защищенным полям:

НЕ используйте префикс для имен полей.

Например, m_это префикс.

Таким образом, публичное раскрытие поля позволяет использовать thisключевое слово, как описано в MSDN

Чтобы квалифицировать участников, скрытых под похожими именами, например: Копировать

public Employee(string name, string alias) 
{
   this.name = name;
   this.alias = alias;
}

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

Лично мне не нравятся подчеркивания в именах переменных. Я также стараюсь быть последовательным. Таким образом, this.name = name;это хорошее практическое правило для работы в общественных и частных сценариях.

В нашей команде мы приняли стандарт использования спецификатора this.or Me.в больших классах, чтобы помочь начинающим разработчикам с большей готовностью различить точную / непосредственную область действия переменной, просто взглянув на нее.

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

StyleCop навязывает использование So. this.Так что, если вы считаете это наилучшей практикой (что я и делаю), то использование this.- лучшая практика.

Стиль, который вы принимаете, зависит от вас и ваших собственных стандартов кодирования. «Лучший» - это то, что вы определяете. Просто будь последовательным. Непоследовательное использование этого просто приводит к путанице.

Мое рассуждение состоит в том, что использование this.вызывает тот факт, что вы ссылаетесь на свойства экземпляра, поэтому, например, это помогает выделить тот факт, что вы изменяете их (если они есть this.x = ...), о чем вы, возможно, захотите узнать. Это также подчеркивает тот факт, что каждый раз, когда вы видите, this.ваш метод никогда не может быть статичным. Использование некоторого соглашения, как, например m_, также сделает это, но это ручное усилие, если вы превращаете m_в статический или реорганизуете какой-то метод для передачи значения извне класса, тогда вы должны помнить, чтобы изменить имя, если вы использовали thisтогда компилятор заставит вас внести изменения.

Проще говоря, использовать thisпроще, потому что, если вы ошиблись, ваш код не скомпилируется, если вы используете m_его вручную, и вы не используете инструменты.

Одной из приятных особенностей использования m_является то, что как только вы вводите маленький mintellisense, вы получаете список всех ваших личных переменных, лично я считаю, что это является плюсом в его пользу; Я также хотел бы пойти s_на частные статические и c_частные константы по аналогичным причинам. Это венгерская нотация, но в том смысле, что она имела в виду, потому что она добавляет полезное значение к имени переменной, так что любой другой программист может сказать об этом вещи по ее имени, которые могут быть не совсем очевидными.

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

thisявный Это оптический знак, который нельзя пропустить.

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

Я всегда использую «это». Рассуждение основано на двух простых фактах:

• Читать код сложнее, чем писать код.
• Вы читаете код чаще, чем пишете код.

Использование «this» делает совершенно очевидным для любого читающего (т.е. не только автора, но может включать автора через 6 месяцев после того, как о деталях реализации полностью забытого), что да, это член класса, который мы » мы говорим здесь «m_» и тому подобное - это просто соглашение, и, как и любое другое соглашение, его можно использовать не по назначению (или вообще не использовать) - нет ничего, что могло бы обеспечить выполнение «m_» / etc во время компиляции или во время выполнения. «this» сильнее: вы можете поместить «m_» в локальную переменную, и компилятор не будет жаловаться; Вы не можете сделать это с "этим".

Во всяком случае, я сожалею, что использование «this» не было обязательным в языковых спецификациях.

В качестве приятного бонуса, при отладке вы можете навести (или добавить часы) «это» и проверить всех остальных учеников - ценная информация.

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

Пример:

public class Example {

    string reason;
    string cause;

    Example (string reason, string cause) {
        this.reason = reason;
        this.cause = cause;
    }

    //<Setter> if you want to explicitly write your onw
    public void setReason(stirng reason) {
        this.reason = reason;
    }
}

Это (например this.reason = reason) в основном присваивает значение из параметров переменным в классе. thisв основном берет класс reasonиз блока параметров.

Я тоже размышлял об этом в течение некоторого времени. Сделав некоторое обширное кодирование в javascript, я поймал себя на том, this.что чаще использую в своем коде на c # (до этого я использовал его почти исключительно в конструкторах или аналогичных методах, чтобы избежать двусмысленности). Это делает код немного более понятным для небольших дополнительных усилий, более того, вы не заканчиваете калечением имен членов вашего класса с помощью префиксов и все же можете вернуться к использованию членов «коротким путем», когда контекст ясен или в особенно сложных выражениях. Я просто добавляю this., когда у меня есть более длинный метод, более длинный список аргументов или объявлено много локальных переменных, и я думаю, что код может извлечь выгоду из некоторой дополнительной ясности, даже если она принудительная.

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

Я предпочитаю префикс подчеркивания для учеников. _someVar;

Почему? Сначала вы знаете, что это член, а не переменная стека. Просто удобство при быстром взгляде. И это занимает меньше беспорядка по сравнению с ключевым словом "это".

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

Я всегда определяю поля с именами, похожими на, myFieldа имена параметров и имена локальных переменных также похожи на myField. Никаких подчеркиваний, никаких префиксов. Я использую thisвезде, где я ссылаюсь на поле. Таким образом, я могу отличить поля от локальных переменных и аргументов без какого-либо префикса. Конечно, в таком случае необходимо thisключевое слово:

public Person(string firstName)
{
    this.firstName = firstName;
}

Поэтому мои свойства выглядят так (да, я всегда помещаю поле со свойством, а не где-то, не связанным с вершиной моего файла):

private string firstName;
public string FirstName
{
    get { return this.firstName; }
}

Хорошо читается: верни это имя .

РЕДАКТИРОВАТЬ: Мой ответ явно не ответ. Итак, вот редактирование. В руководящих принципах кодирования Microsoft говорится:

2.6 Наименование

Не используйте префикс для переменных-членов ( , m , s_ и т. Д.). Если вы хотите различать> локальные переменные и переменные-члены, вы должны использовать «this». в C # и «Я». в VB.NET

Можно найти по адресу: http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx

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

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

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

это кажется мне одним из тех соглашений "что это такое" против правильных соглашений о присвоении имен "что он делает". Краткость следует отдавать предпочтение выше явной. Этот урок часто повторяется динамическими языками. Нам не нужен весь пух!

это. часто может привести к нежелательному шуму.

Вот мое решение:

• parameter_names_
• local_variables
• ANY_CONSTANT
• _private_members
• NonPrivateProperties
• _NonPrivateProperty // Backer
• частная собственность
• _privateProperty // спонсор