Какова цель nameof?

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

Возьмем этот пример:

switch (e.PropertyName)
{
    case nameof(SomeProperty):
    { break; }

    // opposed to
    case "SomeOtherProperty":
    { break; }
}

В первом случае переименование SomeProperty вызовет ошибку компиляции, если вы не измените и определение свойства, и выражение nameof(SomeProperty). Во втором случае переименование SomeOtherProperty или изменение строки "SomeOtherProperty" приведет к незаметному нарушению поведения во время выполнения без ошибок или предупреждений во время сборки.

Это очень полезный способ избежать компиляции кода и отсутствия ошибок (вроде как).

(очень хорошая статья из Эрик Липперт, почему infoof не попал, а nameof -)

Это действительно полезно для ArgumentException и его производных:

public string DoSomething(string input) 
{
    if(input == null) 
    {
        throw new ArgumentNullException(nameof(input));
    }
    ...

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

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

В вашем примере nameof(T) получает имя параметра типа - это тоже может быть полезно:

throw new ArgumentException(nameof(T), $"Type {typeof(T)} does not support this method.");

Другое использование nameof - для перечислений - обычно, если вам нужно строковое имя перечисления, вы используете .ToString():

enum MyEnum { ... FooBar = 7 ... }

Console.WriteLine(MyEnum.FooBar.ToString());

> "FooBar"

На самом деле это относительно медленно, поскольку .Net хранит значение перечисления (т.е. 7) и находит имя во время выполнения.

Вместо этого используйте nameof:

Console.WriteLine(nameof(MyEnum.FooBar))

> "FooBar"

Теперь .Net заменяет имя перечисления строкой во время компиляции.

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

// Property with notify of change
public int Foo
{
    get { return this.foo; }
    set
    {
        this.foo = value;
        PropertyChanged(this, new PropertyChangedEventArgs(nameof(this.Foo));
    }
}

Or...

// Write a log, audit or trace for the method called
void DoSomething(... params ...)
{
    Log(nameof(DoSomething), "Message....");
}

Другой вариант использования, когда nameof функция C # 6.0 становится удобной. Рассмотрим библиотеку, например Dapper, который значительно упрощает получение БД. Несмотря на то, что это отличная библиотека, вам необходимо жестко указать имена свойств / полей в запросе. Это означает, что если вы решите переименовать свое свойство / поле, высока вероятность того, что вы забудете обновить запрос, чтобы использовать новые имена полей. Благодаря интерполяции строк и функциям nameof код становится намного проще в обслуживании и становится безопасным с точки зрения типов.

Из примера, приведенного в ссылке

без имени

var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });

с именем

var dog = connection.Query<Dog>($"select {nameof(Dog.Age)} = @Age, {nameof(Dog.Id)} = @Id", new { Age = (int?)null, Id = guid });

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

Например:

public void DoStuff(object input)
{
    if (input == null)
    {
        throw new ArgumentNullException(nameof(input));
    }
}

Это хорошо. Если я изменю имя переменной, код сломается, а не вернет исключение с неверным сообщением.

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

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

Самый распространенный вариант использования, который я могу придумать, - это работа с интерфейсом INotifyPropertyChanged. (В основном все, что связано с WPF и привязками, использует этот интерфейс)

Взгляните на этот пример:

public class Model : INotifyPropertyChanged
{
    // From the INotifyPropertyChanged interface
    public event PropertyChangedEventHandler PropertyChanged;

    private string foo;
    public String Foo
    {
        get { return this.foo; }
        set
        {
            this.foo = value;
            // Old code:
            PropertyChanged(this, new PropertyChangedEventArgs("Foo"));

            // New Code:
            PropertyChanged(this, new PropertyChangedEventArgs(nameof(Foo)));           
        }
    }
}

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

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

Чаще всего используется проверка ввода, например

//Currently
void Foo(string par) {
   if (par == null) throw new ArgumentNullException("par");
}

//C# 6 nameof
void Foo(string par) {
   if (par == null) throw new ArgumentNullException(nameof(par));
}

В первом случае, если вы реорганизуете метод, изменяя имя параметра par, вы, вероятно, забудете изменить это в ArgumentNullException. С nameof вам не о чем беспокоиться.

См. Также: nameof (Справочник по C # и Visual Basic)

В проекте ASP.NET Core MVC используется nameof в _ 2_ и _ 3_ с RedirectToAction методом для ссылки на действие в контроллере.

Пример:

return RedirectToAction(nameof(HomeController.Index), "Home");

Это означает:

return RedirectToAction("Index", "Home");

и переводит пользователя к действию «Индекс» в контроллере «Домой», то есть /Home/Index.

Допустим, вам нужно напечатать имя переменной в вашем коде. Если вы напишете:

int myVar = 10;
print("myVar" + " value is " + myVar.toString());

а затем, если кто-то реорганизует код и использует другое имя для myVar, ему / ей придется искать строковое значение в вашем коде и соответственно изменять его.

Вместо этого, если вы напишете:

print(nameof(myVar) + " value is " + myVar.toString());

Это помогло бы автоматически выполнить рефакторинг!

Статья MSDN перечисляет маршрутизацию MVC ( пример, который действительно ударил по концепции для меня) среди нескольких других. В (отформатированном) параграфе описания говорится:

• Сообщая об ошибках в коде
• подключение ссылок модель-представление-контроллер (MVC)
• события об изменении свойства срабатывания и т. д.

часто требуется записать строковое имя метода. Использование nameof помогает сохранить действующий код при переименовании определений.

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

Принятые / самые популярные ответы уже дают несколько отличных конкретных примеров.

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

Я хотел бы добавить, что это действительно хорошая идея с точки зрения рефакторинга, поскольку она делает этот рефакторинг строк безопасным. Раньше я использовал статический метод, который использовал отражение для той же цели, но это сказывалось на производительности во время выполнения. Оператор nameof не влияет на производительность во время выполнения; он выполняет свою работу во время компиляции. Если вы посмотрите на код MSIL, вы найдете встроенную строку. См. Следующий метод и его дизассемблированный код.

static void Main(string[] args)
{
    Console.WriteLine(nameof(args));
    Console.WriteLine("regular text");
}

// striped nops from the listing
IL_0001 ldstr args
IL_0006 call System.Void System.Console::WriteLine(System.String)
IL_000C ldstr regular text
IL_0011 call System.Void System.Console::WriteLine(System.String)
IL_0017 ret

Однако это может быть недостатком, если вы планируете обфускировать свое программное обеспечение. После обфускации встроенная строка может больше не соответствовать имени элемента. Механизмы, основанные на этом тексте, сломаются. Примеры для этого, включая, помимо прочего, следующие: Reflection, NotifyPropertyChanged ...

Определение имени во время выполнения требует некоторой производительности, но безопасно для обфускации. Если обфускация не требуется и не планируется, я бы рекомендовал использовать оператор nameof.

Цель оператора nameof - предоставить имя источника артефактов.

Обычно имя источника совпадает с именем метаданных:

public void M(string p)
{
    if (p == null)
    {
        throw new ArgumentNullException(nameof(p));
    }
    ...
}

public int P
{
    get
    {
        return p;
    }
    set
    {
        p = value;
        NotifyPropertyChanged(nameof(P));
    }
}

Но это может быть не всегда:

using i = System.Int32;
...
Console.WriteLine(nameof(i)); // prints "i"

Or:

public static string Extension<T>(this T t)
{
    return nameof(T); returns "T"
}

Одно из применений, которое я давал ему, - это именование ресурсов:

[Display(
    ResourceType = typeof(Resources),
    Name = nameof(Resources.Title_Name),
    ShortName = nameof(Resources.Title_ShortName),
    Description = nameof(Resources.Title_Description),
    Prompt = nameof(Resources.Title_Prompt))]

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

Другой вариант использования nameof - это проверка страниц вкладок, вместо проверки индекса вы можете проверить свойство Name страниц вкладок следующим образом:

if(tabControl.SelectedTab.Name == nameof(tabSettings))
{
    // Do something
}

Менее беспорядочно :)

Я считаю, что nameof увеличивает удобочитаемость очень длинных и сложных операторов SQL в моих приложениях. Это выделяет переменные из этого моря строк и избавляет вас от необходимости выяснять, где переменные используются в ваших операторах SQL.

public bool IsFooAFoo(string foo, string bar)
{
    var aVeryLongAndComplexQuery = $@"SELECT yada, yada
    -- long query in here
    WHERE fooColumn = @{nameof(foo)}
    AND barColumn = @{nameof(bar)}
    -- long query here";


    SqlParameter[] parameters = {
        new SqlParameter(nameof(foo), SqlDBType.VarChar, 10){ Value = foo },
        new SqlParameter(nameof(bar), SqlDBType.VarChar, 10){ Value = bar },
    }
}

Ключевое слово nameof используется для настройки Binding в wpf программно.

чтобы установить Binding, вы должны установить Path со строкой, а с ключевым словом nameof можно использовать опцию Refactor.

Например, если у вас есть IsEnable свойство зависимостей в вашем UserControl и вы хотите привязать его к IsEnable некоторому CheckBox в вашем UserControl, вы можете использовать эти два кода:

CheckBox chk = new CheckBox();
Binding bnd = new Binding ("IsEnable") { Source = this };
chk.SetBinding(IsEnabledProperty, bnd);

и

CheckBox chk = new CheckBox();
Binding bnd = new Binding (nameof (IsEnable)) { Source = this };
chk.SetBinding(IsEnabledProperty, bnd);

Очевидно, что первый код не может рефакторинг, а второй ...

Раньше мы использовали что-то вроде этого:

// Some form.
SetFieldReadOnly( () => Entity.UserName );
...
// Base form.
private void SetFieldReadOnly(Expression<Func<object>> property)
{
    var propName = GetPropNameFromExpr(property);
    SetFieldsReadOnly(propName);
}

private void SetFieldReadOnly(string propertyName)
{
    ...
}

Причина - безопасность времени компиляции. Никто не может молча переименовать свойство и нарушить логику кода. Теперь мы можем использовать nameof ().

Это имеет преимущество при использовании ASP.Net MVC. Когда вы используете помощник HTML для создания некоторого элемента управления, он использует имена свойств в атрибуте имени ввода html:

@Html.TextBoxFor(m => m.CanBeRenamed)

Получается что-то вроде этого:

<input type="text" name="CanBeRenamed" />

Итак, теперь, если вам нужно проверить свое свойство в методе Validate, вы можете сделать это:

public IEnumerable<ValidationResult> Validate(ValidationContext validationContext) {
  if (IsNotValid(CanBeRenamed)) {
    yield return new ValidationResult(
      $"Property {nameof(CanBeRenamed)} is not valid",
      new [] { $"{nameof(CanBeRenamed)}" })
  }
}

Если вы переименуете свое свойство с помощью инструментов рефакторинга, ваша проверка не будет нарушена.