Подчеркнуть или не подчеркнуть, вот в чем вопрос

Есть ли проблемы с отсутствием префикса для частных полей с подчеркиванием в C #, если двоичная версия будет использоваться другими языками фреймворка? Например, поскольку C # чувствителен к регистру, вы можете вызвать поле «foo» и общедоступное свойство «Foo», и оно будет работать нормально.

Будет ли это иметь какой - либо эффект на регистронезависимом языке, как VB.NET, будет ли какое - либо CLS-соответствие (или другими) проблемами , если имена различимы только кожух?

Это не повлияет.

Часть рекомендаций по написанию CLS-совместимых библиотек состоит в том, чтобы НЕ иметь двух общедоступных / защищенных объектов, которые различаются только регистром, например, вы НЕ должны иметь

public void foo() {...}

и

public void Foo() {...}

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

ВАЖНОЕ ОБНОВЛЕНИЕ (12 апреля 2016 г.):

Мы обратили внимание на то, что внутренний стандарт команды .NET CoreFX настаивает на использовании символа подчеркивания без объяснения причин. Однако , если мы внимательно посмотрим на правила # 3 становится очевидным , что существует система _, t_, s_префиксов, предполагает , почему _был выбран в первую очередь.

3. Мы используем _camelCaseвнутренние и частные поля и используем только чтение там, где это возможно. Префикс полей экземпляра с _, статические поля с s_и поток статических полей с t_. При использовании в статических полях readonlyдолжен стоять после static(т. Е. static readonlyНет readonly static).
4. Мы избегаем без 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-notation сохраняет имена нетронутыми

Познавательная нагрузка

• нотация подчеркивания непоследовательна, она заставляет вас обращаться с полями особым образом, но вы не можете использовать ее с другими членами, каждый раз, когда вам нужно спрашивать себя, нужно ли вам свойство или поле

• эта-нотация согласована, вам не нужно думать, вы просто всегда используете "this" для обозначения любого члена

ОБНОВЛЕНИЕ: как было указано, следующее не является преимуществом

Обслуживание

• нотация подчеркивания требует, чтобы вы внимательно следили за _рефакторингом, например, превращая поле в свойство (удалить _) или наоборот (добавить _)

• this-notation не имеет такой проблемы

Автозаполнение

Когда вам нужно увидеть список членов экземпляра:

• нотация подчеркивания не очень помогает, потому что, когда вы набираете "_", всплывающее окно автозаполнения показывает вам частные поля и все типы, доступные из связанных сборок, смешанные с остальными членами экземпляра
• this-notation дает вам четкий ответ, набрав "this", вы видите только список участников и ничего больше

неоднозначность

Иногда приходится иметь дело с кодом без помощи Intellisense. Например, когда вы проводите обзор кода или просматриваете исходный код в Интернете.

• нотация подчеркивания неоднозначна: когда вы видите Something.SomethingElse, вы не можете определить, является ли Something классом, а SomethingElse - его статическим свойством ... или, может быть, Something является свойством текущего экземпляра, которое имеет собственное свойство SomethingElse

• Эта нотация ясна: когда вы видите Something.SomethingElse, это может означать только класс со статическим свойством, и когда вы видите this.Something.SomethingElse, вы знаете, что Something является членом, а SomethingElse - его свойством

Методы расширения

Вы не можете использовать методы расширения в самом экземпляре, не используя this.

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

Поддержка Visual Studio

• нотация подчеркивания не имеет встроенной поддержки в Visual Studio

• Эта нотация, естественно, поддерживается Visual Studio:

  1. "Это." Квалификация : предпочитать предварять все нестатические поля, используемые в нестатических методах, this.в C #.

Официальные рекомендации

Существует множество официальных правил, в которых четко сказано «не использовать символы подчеркивания», особенно в C #.

• нотация подчеркивания пришла из C ++, где это общая практика, которая помогает избежать конфликтов имен, также рекомендуется для VisualBasic.Net для решения проблемы, когда поле «значение» и свойство «Значение» фактически имеют одно и то же имя, потому что VisualBasic нечувствителен к регистру

  1. Объявленные имена элементов в Visual Basic
  2. Резервные поля в VisualBasic.NET

• эта-нотация рекомендуется для C #, а "_" явно запрещена:

  1. это ключевое слово в C #
  2. Рекомендации по использованию полей : не применяйте префикс к именам полей или статическим именам полей.
  3. Рекомендации для имен: Имена членов типа : не используйте префикс для имен полей.
  4. Общее соглашение об именах : X НЕ используйте символы подчеркивания, дефисы или любые другие не буквенно-цифровые символы.
  5. Правило утверждения качества CA1707 : идентификаторы не должны содержать подчеркивания
  6. Использование подчеркивания несовместимо с CLS (для общедоступных и защищенных идентификаторов)
  7. Внутреннее соглашение разработчиков .NET Framework об именах : не используйте префикс для переменных-членов. Если вы хотите различать локальные переменные и переменные-члены, вы должны использовать «this». в C # и "Я". в VB.NET.

Взято из файла справки Microsoft StyleCop:

TypeName: FieldNamesMustNotBeginWithUnderscore

CheckId: SA1309

Причина: имя поля в C # начинается с символа подчеркивания.

Описание правила:

Нарушение этого правила происходит, когда имя поля начинается с символа подчеркивания.

По умолчанию StyleCop запрещает использование символов подчеркивания, m_ и т. Д. Для обозначения полей локального класса в пользу «this». префикс. Преимущество использования this. заключается в том, что он в равной степени применяется ко всем типам элементов, включая методы, свойства и т. д., а не только к полям, благодаря чему все вызовы членов класса мгновенно распознаются, независимо от того, какой редактор используется для просмотра кода. Еще одно преимущество состоит в том, что он позволяет быстро различать члены экземпляра и статические элементы, которые не имеют префикса.

Если имя поля или переменной должно соответствовать имени элемента, связанного с Win32 или COM, и, следовательно, должно начинаться с подчеркивания, поместите поле или переменную в специальный класс NativeMethods. Класс NativeMethods - это любой класс, который содержит имя, оканчивающееся на NativeMethods, и предназначен для использования в качестве заполнителя для Win32 или COM-оболочек. StyleCop проигнорирует это нарушение, если элемент помещен в класс NativeMethods.

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

Изменить: в качестве продолжения страница проекта StyleCop находится здесь: https://github.com/DotNetAnalyzers/StyleCopAnalyzers . Прочитав файл справки, вы сможете понять, почему они предлагают различные стилистические правила.

Поскольку мы говорим о закрытом поле, оно не влияет на пользователя вашего класса.

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

private int foo;
public void SetFoo(int foo)
{
  // you have to prefix the private field with "this."
  this.foo = foo;

  // imagine there's lots of code here,
  // so you can't see the method signature



  // when reading the following code, you can't be sure what foo is
  // is it a private field, or a method-argument (or a local variable)??
  if (foo == x)
  {
    ..
  }
}

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

После работы в среде, которая с тех пор имела очень специфические и очень бессмысленные правила стиля, я продолжил создавать свой собственный стиль. Это тот тип, который я много раз перебрасывал. Я, наконец, решил, что частные поля всегда будут _field, локальные переменные никогда не будут иметь _ и будут в нижнем регистре, имена переменных для элементов управления будут примерно соответствовать венгерской нотации, а параметры обычно будут верблюжьими.

Я ненавижу this.ключевое слово, которое, на мой взгляд, просто добавляет слишком много шума кода. Мне нравится, что Resharper удаляет лишнее. ключевое слово.

Обновление за 6 лет: я анализировал внутреннее устройство Dictionary<TKey,T>для конкретного использования одновременного доступа и неправильно считал частное поле как локальную переменную. Частные поля определенно не должны совпадать с соглашением об именах, что и локальные переменные. Если бы там было подчеркивание, это было бы невероятно очевидно.

Мне нравится подчеркивание, потому что тогда я могу использовать имя в нижнем регистре в качестве параметров метода, например:

public class Person
{
    string _firstName;

    public MyClass(string firstName)
    {
        _firstName = firstName;
    }

    public string FirstName
    {
        get { return _firstName; }
    }
}

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

Однако в последнее время я обнаружил, что использование префикса подчеркивания для закрытых членов не одобряется, хотя я не совсем уверен, почему. Может, кто-то еще знает? Это просто принцип префикса? Или было что-то связанное с изменением имен общих типов, которые получают подчеркивание в скомпилированных сборках или что-то в этом роде?

Рекомендация Style Cop или нет, но копание в .NET Framework показывает частое использование "_" для переменных-членов. Что бы ни рекомендовали создатели Style Cop, это не то, что используют большинство сотрудников MS. :) Так что я буду придерживаться символа подчеркивания. Потому что я лично делаю намного меньше ошибок, используя подчеркивание, чем this (пример: использование varName = varName вместо this.varName = varName, это действительно застряло во мне)

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

public int Foo
{
   private int foo;
   get
   {
      return foo;
   }
   set
   {
      foo = value;
   }
}

Это позволило бы полностью отказаться от использования полей.

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

Обозначение _fieldName для частных полей очень легко сломать . Используя "this." обозначение нарушить невозможно. Как бы вы нарушили обозначение _? Заметим:

private void MyMethod()
{
  int _myInt = 1; 
  return; 
}

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

Сравните это с Ruby, где имя переменной @my_numberсвязывает имя с областью видимости и не может быть разрушено.

изменить: этот ответ стал отрицательным. Мне все равно, это останется.

Если вы хотите, чтобы ваша сборка была CLS-совместимой, вы можете использовать атрибут CLSCompliant в вашем файле assemblyinfo. Затем компилятор будет жаловаться, если ваш код содержит материал, который не соответствует требованиям cls.

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

(Но я также всегда ставлю перед своими закрытыми членами знак подчеркивания. Это также помогает мне, когда я читаю свой код, ясно давать понять, что определенная переменная является полем члена).

Мне нравится использовать подчеркивание перед личными полями по двум причинам. Об одном уже упоминалось, поля выделяются среди связанных с ними свойств в коде и в Intellisense. Вторая причина в том, что я могу использовать одни и те же соглашения об именах независимо от того, кодирую ли я на VB или C #.

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