Подтвердить что ты не робот

Есть ли какое-либо соглашение о присвоении имен С# для переменной, используемой в свойстве?

Скажем, у нас есть переменная, которую мы хотим назвать Fubar

Скажем, что Fubar есть String!

Это означает, что мы определяем Fubar следующим образом:

public string Fubar;

Теперь предположим, что мы хотим, чтобы Fubar имел геттер и сеттер (или, другими словами, стал свойством С#)!

private string Fubar;
public string Fubar_gs
{
    get
    {
        //Some fancy logic
        return Fubar;
    }
    set
    {
        //Some more fancy logic
        Fubar = value;
    }
}

Хорошо! Это все прекрасно и денди, ЗА ИСКЛЮЧЕНИЕМ, что если бы я хотел, чтобы PROPERTY назывался Fubar, а не исходная переменная?

Ну, очевидно, я бы просто переименовал обе переменные. Но проблема в том, что было бы лучшим именем для исходной переменной?

Существует ли соглашение об именах для этой ситуации?

4b9b3361

ОТВЕТЫ

Ответ 1

В соответствии с соглашениями Microsoft об именах правильным способом будет:

private string fubar;
public string Fubar { get { return fubar; } set { fubar = value; } }

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

Таким образом, часто можно увидеть:

private string _fubar;
public string Fubar { get { return _fubar; } set { _fubar = value; } }

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

В С# 6 появился новый синтаксис для объявления значений по умолчанию для свойств или создания свойств только для чтения, уменьшая потребность в свойствах с вспомогательными полями, которые не имеют никакой специальной дополнительной логики в методах get и set. Вы можете просто написать:

public string Fubar { get; set; } = "Default Value";

или

public string Fubar { get; } = "Read-only Value";

Ответ 2

префикс private с подчеркиванием _Fubar

Ответ 3

Если вы назовете свои личные переменные, начиная с нижнего регистра, вы можете щелкнуть правой кнопкой мыши по ним, и VS будет генерировать ваш код getter/setter;

Refactor- > Enacpsulate Field...

Он назовет свойство с помощью Caps.

Ответ 5

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

Подход 1

private string _fubar;   //_camelCase
public string Fubar { ... }

Подход 2

private string fubar;    //camelCase
public string Fubar{ ... }

Подход 3

private string _Fubar;    //_PascalCase
public string Fubar{ ... }

Также существуют фреймворки, которые занимают много творчества, например, используют свойство и документируют его как переменную-член и, таким образом, используют стили элементов вместо стилей свойств (да, Unity! Я указываю палец на вас и ваш MonoBehaviour.transform свойство/элемент)

Чтобы устранить несогласованность в нашей базе кода , мы используем наше домашнее правило:

  • Попытайтесь использовать более правильное именование, обычно член, используемый внутри публичного свойства, имеет несколько другую цель, чем его публичный аналог, поэтому очень часто можно найти другое и правильное имя, и если это невозможно, просто удерживая состояние для публичной собственности, так почему бы не назвать его nameValue?
  • используйте autoproperties, если возможно

С нашим подходом в большинстве случаев мы избегаем сомнений в подчеркивании "_", в то же время имея гораздо более читаемый код.

private string fubarValue; //different name. Make sense 99% of times
public string Fubar { ... }

Ответ 6

Хорошо, документ Руководства по проектированию инфраструктуры гласит следующее:

Имена полей Правила именования полей применяются к статическим открытым и защищенным полям. Внутренние и частные поля не охватываются правилами, а открытые или защищенные поля экземпляров не допускаются правилами разработки элементов.

✓ НЕ используйте PascalCasing в именах полей.

✓ НУЖНО назвать поля, используя существительное, словосочетание или прилагательное.

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

Например, не используйте "g_" или "s_" для обозначения статических полей.

Так что для частных полей официальной рекомендации нет. Однако, если вы используете быстрое действие VS 2017 "Преобразовать в полное свойство" для свойства, это происходит:

VS 2017 quick action "Convert to full property"

Таким образом, кажется, что можно с уверенностью предположить, что добавление префикса к частным полям с подчеркиванием является несколько стандартным.

Ответ 7

Путь С#

private string _fubar;
public string Fubar
{
    get
    {
        return _fubar;
    }
    set
    {
        _fubar = value;
    }
}

Однако, если это просто базовый getter/setter без дополнительной логики, вы можете просто написать

public string Fubar { get; set; }

Нет необходимости в резервной переменной или что-то еще.

Ответ 8

Хорошая вещь о стандартах кодирования заключается в том, что есть так много на выбор:

Выберите подходящее вам соглашение и последовательно используйте его.

Соглашение Microsoft -— Частные поля pascalCase и свойства CamelCase являются аккуратными, но могут приводить к ошибкам из-за опечаток. Я нахожу, что основное подчеркивание, вызывающее раздражение, вызывает два дополнительных нажатия клавиш каждый раз, когда вы вводите имя, но вы так сильно не получаете опечатки (или, по крайней мере, компилятор их ловит).

Ответ 9

Другой способ объявить со значением по умолчанию

    private string _fubar = "Default Value";
    public string Fubar
    {
        get { return _fubar; }
        set { _fubar = value; }
    }

Ответ 10

Хотя большинство разработчиков следуют рекомендациям Microsoft, как разработчики игр, мы придерживаемся стиля Unity как (один из исходных кодов скриптов здесь):

static protected Material s_DefaultText = null;
protected bool m_DisableFontTextureRebuiltCallback = false;
public TextGenerator cachedTextGenerator { ... }

Ответ 11

Я думаю, одно имя лучше:

public string Fubar { get; private set; }