Using “value” as an identifier in C#

Question

In writing short helper functions, I often find myself wanting to use the variable identifier \"value\" as an argument. It seems as though Visual Studio compiles this just f

Answer 1

As other have answered value is reserved for properties, however value it is not reserved specifically for methods, therefore, you can use value for variables everywhere other then properties setter

However if you set value in the get it will work just fine.

Good

public int MyProperty { get { int value = 0; return value; }}

Not good

public int MyProperty { get { ... } set { int value = 0; _MyProperty = value }}

Answer 2

It is fine to use value as an identifier anywhere outside a set accessor. The C# Language Specification (linking old version) says:

Since a set accessor implicitly has a parameter named value, it is a compile-time error for a local variable or constant declaration in a set accessor to have that name.

The Word value is not (and was never) a full keyword in C#, even if it has had this special use in setters ever since C# 1.

See value (C# Reference) for more.

Of course, if you have a field (class-level variable) called value and you want to access it from within a set accessor, use this.value (or NameOfYourType.value for static fields).

---

For a list of real keywords and contextual "keywords", also see C# Keywords.

Answer 3

Here's what MSDN says:

The set accessor resembles a method whose return type is void. It uses an implicit parameter called value, whose type is the type of the property.

The properties are basically syntactic sugar that avoids you having to write a lot of get_Bar and set_Bar methods (note: there are some other advantages too, the CLR knows it's a property). For example, if you have a class like this:

public class Foo
{
    private int _bar;
    public int Bar
    {
        get { return _bar; }
        set { _bar = value; }
    }
}

It'll generate IL (for the setter) that looks something like this:

.method public hidebysig specialname 
            instance void  set_Bar(int32 'value') cil managed
    {
      // 
      .maxstack  8
      IL_0000:  nop
      IL_0001:  ldarg.0
      IL_0002:  ldarg.1
      IL_0003:  stfld      int32 Program/Foo::_bar
      IL_0008:  ret
    } // end of method Foo::set_Bar

The thing to note here is that the set_Bar method takes a parameter called value. So not only does it "resemble" a method whose return type is void with a parameter called value, it actually is that.

So you can't use value for something else in a setter, obviously.

Now should you use it elsewhere? It depends. If it's obvious what it's referring to in the context where you are using it then sure. If value is ambiguous in a particular context then use something more explicit.

From MSDN:

The contextual keyword value is used in the set accessor in ordinary property declarations.

It makes no mention of any other context where value is considered a keyword, so aside from a setter, or anywhere else where it might have been defined already, you should be fine using value. Is it bad practice? Not as a rule, no more than any other potentially ambiguous variable name.

Edit: One place where I think having value as a name would be really problematic would be as a field (or worse a property) in a class. For example:

public class Foo
{
    private int value;
    public int Value
    { 
        get { return value; }
        set { value = value; }    // which `value` are you setting? and to what?
    }
 }

Now you could remove the ambiguity here with this.value = value, but it still ugly and it seems better to me to just use a different name for you field.

Answer 4

In a property setter, the variable name value is reserved. It is used as the name of the variable which can be assigned to a backing field.

The question: Is it always safe to use "value" as a variable name outside of a property setter? If not, when can this be done safely? And, is this considered bad practice?

It's only reserved in the property setter. It's a very generic name, but it can often be the best description of the variable you are working with.

MSDN info

Answer 5

C# has lots of contextual keywords. The main reason for them in new versions of the language is to avoid breaking changes with existing compiling code. Contextual keywords lets them add new semantics, without breaking code that was previously valid.

As mentioned in Eric's article, you can always use @ as a prefix to be able to use a keyword as an identifier. I think the main advantage of that is the ability to interoperate with other libs that may have been developed in other CLR language with a different set of keywords, where a C# keyword (either reserved or contextual) may not be a keyword in that other language.

Answer 6

C# has two types of keywords: global keywords and contextual keywords.

Global keywords may never be used as identifiers. Contextual keywords are reserved only in certain circumstances. For example, you may use most LINQ keywords as variable or method names, when the compiler sees that the code is not a query.

value is reserved only in property setters as the parameter name. Everywhere else you may use it as an identifier, and it often makes sense. I think it's unlikely that this keyword's context will expand, because a lot of programs use it as a parameter name and nobody likes breaking changes.