Here's a question that recently came up on an internal mailing list: how do I create an enum with a name that happens to be a c# keyword?
i definitely agree with your assessement of: don’t do that. on a funny note, i have seen lots of things like the following:
int eger;
var iable;
bool ean;
I agree that you shouldn’t be naming properties and method names the same as keywords. However, this is not a simple problem with a cross language VM platform. If the compiled objects are language independent and each language has different keywords, then you will get conflicts as new languages are ported to the platform.
how about:
public enum test
{
publ1c,
pr1vat3
}
(I knew l337 speak had it’s place in the world!)
also, to quote TheDailyWTF on interested variable names:
double cheeseburger;
char broiled;
long time;
also, consider that
Public and Private wouldn’t cause any fuss because it differs in case. So you’d avoid the @ and follow better naming conventions at the same time.
better naming conventions
I don’t know that I would call two things that differ only in the case of the first letter a “better naming convention”.
That’s an accident waiting to happen.
If the idea is to make code, specifically variable names, self-describing, then this really isnt all that unreasonable.
Lets say, for sake of argument, I am working for an agency that specializes in software for schools.
Some potential attributes for a school are: public, or private.
An enum is a reasonable choice in this instance. Sure, I could use PublicSchool, or PrivateSchool, instead, but that is potentially redundant.
What Damien said. You’ve got a good example in the first code snippet there - the “Dim” keyword in VB.
“Dim” is not a keyword in C#. Creating an enum member called “Dim” in C# is perfectly valid, and doesn’t hurt in the slightest, so there’s no reason not to do it. If you want to access the code from VB.NET though, you need to know how it’s possible.
This goes both ways, and is not guardable against in a general sense as there’s no way of knowing what languages will get ported to .NET in the future (shudder - perl.net?), so it’s impossible to enumerate all the keywords that might be used by all of them.
“Dim” is not a keyword in C#. Creating an enum member called “Dim” in C# is perfectly valid
True, and worth thinking about. But you can use the [] or @ escaped identifiers to get around that edge condition.
is not guardable against in a general sense as there’s no way of knowing what languages will get ported to .NET in the future
Well, right, so why worry about that?
I say focus on today’s problems today (eg, Dim) and deal with future problems when they actually arise.
"I don’t know that I would call two things that differ only in the case of the first letter a “better naming convention”. "
Yeah if you were naming two variables, then definitely I agree with you. But we’re talking about a C# keyword and an improperly cased enumeration (obviously judged by naming standards). What’s the problem with having an enumeration like this:
public enum Destination
{
Home,
Store,
Void
}
or
public enum UnionMemberType
{
Regular,
Delegate
}
none of these stand out as “wrong” to me, the casing differentiates it and follows my naming standard.
A man goes to a doctor’s office. He says, "Doctor, it hurts when I raise my arm over my head."
The doctor replies, “Then don’t raise your arm over your head.”
“But doctor, we need the eggs!”
Oh, sorry, wrong punch line.
" “Dim” is not a keyword in C#. Creating an enum member called “Dim” in C# is perfectly valid
True, and worth thinking about. But you can use the [] or @ escaped identifiers to get around that edge condition. "
But it’s interesting because it means the keyword limiter is embedded in the compiler itself and not in the CLR.(if you can create enums of VB.NET keywords in C#)
On a project a couple years ago our primary domain concept was an “Event,” so of course we named the class Event. Oh, that hurt.
public enum test
{
IsPublic,
IsPrivate
}
public enum test
{
is_public,
is_private
}
Dim e As test = test.IsPrivate
Dim e As test = test.is_private
Try naming conventions in SQL that can contain blanks? Order ID, Key to name a couple are pretty common column fields. Its just always easy as has been said above, to have variable names and enums that make sense within the context of things yet violate the keyword rule.
If a complier is smart enough to handle scoping and multiple iterations of a call and keep track of the scope of those iteratated variables that it would be able to hanlde something like keyword variable names. Wouldn’t it just be an extension of the scoping?
Good thing about having English as second language: you make enums using words in your first language. In my case, “Portuguese”.
public enum teste
{
privado,
publico
}
If you generate C# from an XML Schema using xsd.exe, and it runs into entities with reserved names, it prefixes the class names with @.
Maybe it helps porting code in which those weren’t keywords. Or somehow helps with autogenerated code. Or maybe an escape route for dealing with conflicting future keywords added to the language.
Indeed, why do I have to do this ?
But I will follow another path than you. Your first example was :
Public Enum Test
Public = 1
Private = 2
End Enum
The compiler will say that you can’t use a special keyword inside Enum. But why ? My enum’s names will always be prefixed with the enum :
Test.Public
Test.Private
Can someone see where is the keyword ? All I see is an Enum identifier, followed by a name.
My conclusion is that the compiler is baddly written, because he can’t make the difference when “private” is a modifier or when it’s an enum name.
Yes, why doing it ?
Good programming practice is readability of the code so, even if you hack the compiler to use language keywords, why just making this confusion ?
There is a plenty of words outside there … use it !