Avoiding Language Keyword Conflicts

问题:

How do you guys avoid keyword conflicts in your language?

For example, I'm creating a class (VB 2008) to hold all the configuration variables for some reports we generate. Naturally, one of the variables is "Date". And of course you can't have anything named the same as a keyword. In VB 2008 you do have the option of surrounding a conflicting word with []'s and fix it but I've always seen that as a hack. Any suggestions? What are your names to get around common keywords?

Code to help visualize...

Dim m_Title As String

Dim m_Date As String

Public Property Title() As String
    Get
        Return m_Title
    End Get
    Set(ByVal value As String)
        m_Title = value
    End Set
End Property


Public Property [Date]() As String
    Get

    End Get
    Set(ByVal value As String)

    End Set
End Property 

回答1:

Probably think about more specific nature of the variable?

From your example, the "Date" can be "Created Date" or "Posted Date" or anything else. If you find your variable names too trivial, you may be oversimplifying (or even obfuscating) your code. Help your coworkers by creating a clear but concise variable names.

回答2:

Don't look at [Date] as a hack; if your property represents a date, it should be called Date. Use the tools you have available to get the job done. Personally I feel that properties that have the names they do only to get around such conflicts are more of a hack, since you will get to deal with it every time you use the property.

回答3:

misspell your variable names!

回答4:

On .NET, it is reasonable to consider the Common Language Specification (CLS) as the lowest common denominator that you should cater to. This is documented in ECMA-335 "Common Language Infrastructure (CLI) Partitions I to VI". Here's what it says specifically about names; a note in CLS Rule #4 (8.5.1 "Valid names"):

CLS (consumer): Need not consume types that violate CLS Rule 4, but shall have a mechanism to allow access to named items that use one of its own keywords as the name.

So no, it's not really a hack, but a definite rule. The reason why it's there is that, as .NET is extensible as far as languages targeting it go, you can never avoid name clashes. If you cover C#, there's VB. If you cover C# and VB, there's C++/CLI. If you cover all those, there's F# and Delphi Prism. And so on. Hence why it is mandated by CLS that languages provide a way to escape their keywords as identifiers; and all languages I've listed provide some way to do so (and thus are compliant CLS consumers).

In general, it is still considered good manners to avoid clashes with either C# or VB non-context keywords, mainly because those two languages are the most popular by a very large margin. For example, it is the reason why it's HashSet and not just Set - the latter is a VB keyword. The full listings are:

• C# keywords
• VB keywords

回答5:

Most languages have something to escape any reserved words. C# has @ so you can use @class as an argument name (something MVC adopters are learning).

If the domain states that a certain word be used to describe it then that is what the escaping of reserved words is there for. I wouldn't be afraid to escape reserved words to get my model close to the domain even if it means more typing - the clarity is worth it!

回答6:

To avoid naming conflicts with keywords, I simply don't use keywords.

In your case, Date. Date of what? If I had to maintain your application that would probably be the first thing I'd ask. The great thing about keywords is that they're completely generic, something a variable name should never be.

回答7:

There is no silver bullet, but modern languages help a lot with better abilities to manage namespaces.

In my case, I curse the fact that C has an 'index' command.

回答8:

"Date_" or "_Date".

回答9:

This is one question where Perl dodges the question entirely.

Variables always have one of $%@*&, the only things that can conflict are Globs/Handles, and subroutines.

Even that isn't much of a problem because Globs/Handles aren't used very much any more.

Subroutines and keywords are very much the same in Perl. If you need to get at the built-in subroutine/keyword you can get at it by appending CORE::, for example CORE::dump.

Really I think the only keywords you would have a problem with are sub, my, local, and 'our', because those keywords are parsed very early in parser. Note that you can still create a sub with those names, it just won't work without specifying the full name, or from a blessed reference, or with a symbolic reference.

{
  package test;
  sub my{  print "'my'  called using $_[-1]\n" };
  sub new{ bless {}, $_[0] };
  sub sub{ print "'sub' called using $_[-1]\n" };

  sub symbolic{
    *{__PACKAGE__.'::'.$_[1]}{CODE}->('symbolic reference');
  }

  my $var; # notice this doesn't call test::my()
}

package main;
my $test = test->new;

# Called from a blessed reference
$test->my('blessed reference');
$test->sub('blessed reference');

print "\n";

# Called using the full name
test::my('full name');
test::sub('full name');

print "\n";

# Called using a symbolic reference
$test->symbolic('my');
$test->symbolic('sub');

Output:

'my'  called using blessed reference
'sub' called using blessed reference

'my'  called using full name
'sub' called using full name

'my'  called using symbolic reference
'sub' called using symbolic reference