Підкреслювати або не підкреслювати, це питання

Чи є проблеми з нефіксацією приватних полів з підкресленням у 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, яка працює над критичним, багатопотоковим, системним кодом на рівні продуктивності , то вам НАДІЙНО ЗАПРОШЕНО :

• дотримуватися своїх стандартів кодування та
• використовувати позначення підкреслення та
• більше не читайте цю відповідь

В іншому випадку читайте далі ...

ОРИГІНАЛЬНИЙ ВІДПОВІДЬ:

Давайте спочатку домовимось про те, що ми говоримо. Питання полягає в тому, як ми отримуємо доступ до членів екземплярів у межах нестатичних методів та конструкторів класу / підкласів, якщо модифікатори видимості дозволяють це робити.

Підкреслення-позначення

• пропонує використовувати префікс "_" у назвах приватних полів
• він також говорить, що ніколи не слід використовувати "це", якщо це абсолютно не потрібно

Це-позначення

• пропонує вам просто завжди використовувати "це". для доступу до будь-якого члена примірника

Чому це позначення існує?

Тому що це ти

• скажіть один від одного параметр від поля, коли вони мають спільне ім’я
• переконайтеся, що ви працюєте в контексті поточного примірника

Приклад

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;
   }
}

Можна подумати, що це лише питання особистого смаку, і обидва способи однаково хороші / погані. Однак є певні аспекти, де ця нотація перемагає підкреслення:

Чіткість

• підкреслення символів захаращує імена
• ця нотація зберігає імена недоторканими

Пізнавальне навантаження

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

• це позначення є послідовним, вам не потрібно думати, ви просто завжди використовуєте "це" для позначення будь-якого учасника

ОНОВЛЕННЯ: як було зазначено, наступне не є перевагою

Технічне обслуговування

• Підкреслення нотації вимагає від вас _уважного під час рефакторингу, скажімо, перетворення поля у властивість (видалити _) або навпаки (додати _)

• ця нотація не має такої проблеми

Автозавершення

Коли вам потрібно переглянути список членів екземпляра:

• Підкреслення нотації не дуже допоможе вам, тому що при введенні "_" спливаюче вікно автозаповнення показує вам приватні поля та всі типи, доступні з пов'язаних збірок, змішаних з рештою членів екземпляра
• ця нотація дає вам чітку відповідь, набравши "це", все, що ви бачите, - це список членів і нічого іншого

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

Іноді доводиться мати справу з кодом без допомоги Інтеллісенса. Наприклад, коли ви робите огляди коду або переглядаєте вихідний код в Інтернеті.

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

• ця нотація зрозуміла: коли ви бачите Something.SomethingElse, це може означати лише клас зі статичною властивістю і коли ви бачите це.Something.SomethingElse, ви знаєте, що щось є членом, а SomethingElse - його властивістю

Методи розширення

Не можна використовувати методи розширень у самому екземплярі без використання "цього".

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

Підтримка Visual Studio

• Підкреслення нотацій не має вбудованої підтримки у Visual Studio

• ця нотація підтримується Visual Studio природно:

  1. "Це". Кваліфікація . Віддайте перевагу всім нестатичним полям, які використовуються в нестатичних методах, на this.C #

Офіційні рекомендації

Існує багато офіційних вказівок, які чітко говорять про те, що "не використовуйте підкреслення", особливо в C #

• підкреслення нотатки походить від C ++, де це загальна практика, яка допомагає уникнути конфліктування імен, також рекомендується для VisualBasic.Net для подолання проблеми, коли поле "value" та властивість "Value" насправді мають те саме ім'я, тому що VisualBasic є нечутливим до регістру

  1. Заявлені імена елементів у Visual Basic
  2. Резервне копіювання полів у VisualBasic.NET

• цю нотацію рекомендується використовувати для C #, тоді як "_" прямо заборонено:

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

Взяте з файлу довідки Microsoft StyleCop:

TypeName: FieldNamesMustNotBeginWithUnderscore

CheckId: SA1309

Причина: Назва поля в C # починається з підкреслення.

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

Порушення цього правила відбувається, коли назва поля починається з підкреслення.

За замовчуванням StyleCop забороняє використовувати підкреслення, m_ тощо для позначення полів місцевого класу на користь "цього". префікс. Перевага використання "цього". полягає в тому, що він застосовується однаково до всіх типів елементів, включаючи методи, властивості тощо, а не лише поля, завдяки чому всі виклики членів класу миттєво впізнаються, незалежно від того, який редактор використовується для перегляду коду. Ще одна перевага полягає в тому, що це створює швидку, впізнавану диференціацію між елементами екземпляра та статичними членами, що не буде префіксом.

Якщо ім'я поля чи змінної призначене для узгодження імені елемента, пов’язаного з 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, локальні змінні ніколи не матимуть _ і будуть малі регістри, імена змінних для елементів керування будуть слабко слідувати угорському позначенню, а параметри, як правило, будуть camelCase.

Я ненавиджу 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. :) Тож я буду дотримуватися підкреслення. Оскільки я особисто роблю набагато менше помилок, використовуючи підкреслення, ніж це (наприклад: використання varName = varName замість цього.varName = varName, воно справді застрягло в мені)

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

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

Це дозволило б повністю припинити використання полів.

Єдиний раз, коли я коли-небудь префіксую приватне поле з підкресленням, це коли власність вимагає окремого резервного поля. Це також єдиний раз, коли я використовую приватні поля. (І оскільки я ніколи не використовую захищені, внутрішні чи публічні поля, це єдиний раз, коли я використовую період полів.) Що стосується мене, якщо змінна повинна мати область класу, це властивість класу.

Позначення _fieldName для приватних полів так легко зруйнувати . Використовуючи "це". позначення неможливо розірвати. Як би ви порушили _ позначення? Дотримуйтесь:

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

Ось я просто порушив вашу умову про іменування, але вона складається. Я вважаю за краще конвенцію про іменування, яка не є явною та б) явною. Я за те, щоб позбутися угорського іменування, і це визначило певним чином. Замість типу об'єкта перед іменем змінної у вас є рівень доступу.

Порівнюйте це з Ruby, коли ім'я змінної @my_numberпов'язує ім'я з областю і є нерозривним.

редагувати: Ця відповідь заперечила негативно. Мені все одно, це залишається.

Якщо ви хочете, щоб ваша збірка відповідала CLS, ви можете використовувати атрибут CLSCompliant у вашому файлі Assemblyinfo. Потім компілятор скаржиться, коли ваш код містить речі, які не відповідають стандартам cls.

Потім, коли у вас є 2 властивості, які відрізняються лише у випадку, компілятор видасть помилку. З іншого боку, коли у вас є приватне поле та публічна власність в одному класі, проблем не буде.

(Але я також завжди префіксую своїх приватних членів підкресленням. Це також допомагає мені зрозуміти, коли я читаю свій код, що певна змінна є полем члена).

Мені подобається використовувати підкреслення перед моїми приватними полями з двох причин. Про одне вже згадувалося, поля виділяються з пов'язаних з ними властивостей у коді та в Intellisense. Друга причина полягає в тому, що я можу використовувати ті ж самі умови іменування, чи я кодую в VB чи C #.

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