In C# you can preface any identifier or keyword with the @ symbol to make it a verbatim identifier. This allows you to use what would normally be reserved keywords, like for as identifiers, should you need to.
I’m occasionally asked why it is that any identifier can be made into a verbatim identifier. Why not restrict the verbatim identifiers to the reserved and contextual keywords?
The answer is straightforward. Imagine that we are back in the day when C# 2.0 just shipped. You have a C# 1.0 program that uses yield as an identifier, which is entirely reasonable; “yield” is a common term in many business and scientific applications. Now, C# 2.0 was carefully designed so that C# 1.0 programs that use yield as an identifier are still legal C# 2.0 programs; it only has its special meaning when it appears before return, and that never happened in a C# 1.0 program. But still, you decide that you’re going to mark the usages of yield in your program as verbatim identifiers so that it is more clear to the future readers of the code that it is being used as an identifier, not as part of an iterator.
You wish to do this work before upgrading your entire organization to C# 2.0. It would be both bizarre and counterproductive if doing so made your program no longer a legal C# 1.0 program!
Fabulous adventures in coding 
Huh… interesting. I never knew this existed, and I’ve been using C# for years!
Also, code generators can take as user input the name of an identifier to generate, and not have to figure out whether an `@` is required. Just add it in and be done with it.
My favorite use of verbatim identifiers is in extension methods:
static bool IsNullOrEmpty(this IEnumerable @this) { return @this == null || !@this.Any(); }
Nice pattern!
I hate to be that guy, but seriously why would you ever want to do this?
I can’t imagine it ever making the code any clearer, and since you’re already doing a search and replace just rename it to something that won’t confuse the hell out of all the developers NOT subscribed to this blog!
One important use case is interop with other languages, which have different identifiers. A VB programmer has a different set of reserved keywords, so they might name a class something a C# programmer can’t directly utter (and vice versa).
I clearly remember the first time I learned about this feature. I was quick to label it stupid as I thought it would encourage programmers to name things with keywords and I saw no actual value in it. The very next week I had to consume a Java web service in .NET. The WSDL generator on the Java side was somewhat broken and for every result it had an object with a “return” property where the actual result object was held. The Visual Studio proxy generator used @return to create that property. Since then I’ve never questioned the wisdom of the C# design team. If I think something in C# is stupid I assume I don’t understand it.
@Stilgar, well said.
People have different preferences, if you have this db column return so that would be a prop public string return.. or yet you rename your property as return_col which is will lead to other thinks like decorating attributes instead of a clean property.
On a related note, if a type imported from another language has some members which conflict with reserved words and some which don’t, it may be aesthetically cleaner to prepend *all* identifiers with “@” than do so with just some of them (especially in a mixed-language shop). For example, if a type imported from some other language includes members “boo”, “float”, “for”, “step”, referring to them as @boo, @float, @for, and @step in C#, and [boo], [float], [for], and [step] in VB.NET, would yield a cleaner relationship between the member names in C# and VB.NET code than would using verbatim identifiers only where needed.
@John, at first I agreed with you on the grounds that members are easier to find if they are named consistently. Then, I stumbled into this in the C# 5 spec: Use of the @ prefix for identifiers that are not keywords is permitted, but strongly discouraged as a matter of style.
It also looks like IntelliSense goes a little wonky when they are used. Out of curiosity, I create a field called @for, and the auto-complete list sorts it without respect for the @ sign, so it can be found where you expect it. But if I type “fo” to filter the list down, the @for field is removed from the candidate set. If I rename the field to @foo, then the @ is dropped from the identifier name in the autocomplete list, and all works as expected. I think is an IntelliSense bug since the list doesn’t filter until you enter two characters.
I also learned that it doesn’t matter if a member or type is declared with a verbatim identifier or not (as long as the identifier is not a keyword) it is legal to refer to it either way. References which use a verbatim identifier disable syntax highlighting though, regardless of what the identifier is.
None of these are particularly strong points, but in aggregate they make me think that it might be better to avoid them unless they are necessary.
I can’t find an example right now, but I think NHibernate uses it a good bit for arguments in its reflection heavy APIs, e.g., Map(Type @class). I imagine the justification is that it helps the code be self-documenting. Of course, You could name the argument classType though.
The @ prefix for an identifier is a pretty natural extension to its function for string literals, so on the assumption developers are familiar with that, I don’t think it would be terribly difficult to figure out.
@chris I’ve also seen it used in NHibernate classes that have been translated directly from Java to escape @event as an identifier
It comes up in ASP.NET MVC. It is a common pattern to specify html element attributes using an anonymous object:
new
{
id = “unique”,
@class = “type1 type2 type3”
}
For example, when using Razor view engine in ASP.NET MVC, there are helper methods to render various HTML elements and most of these methods take an object-type parameter specifying HTML attributes of that element. And since “class” is rather common HTML attribute…
It’s often used in Asp.Net MVC with Html attribute anonymous types.
@Html.TextboxFor(m=>m.Text, new { @class = “textboxClass” }))
Are you implying that “yield_” or “_yield” is superior to “@yield”? Because sometimes there is just no better name for the thing — for example, if a field of a C struct is called “this”, you really have a few choices when porting it to C#: it has to have “this” in its name, or people will get upset and confused.
Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1438
Here’s a question I feel is interesting and worthy (@Eric, but also @everyone <– not reserved keywords, as far as I know): What is the most egregious bug you have encountered, the root cause of which was verbatim identifiers?
I'd be interested to know the answer from the compiler implementation level and from the every-day-user level.
I once wrote a C# parser to automate some code validations and used verbatim identifiers to declare variables for tokens: var @using = …, var @class = …, var @struct = …, etc.