Предотвращение конфликтов ключевых слов - PullRequest
0 голосов
/ 17 июля 2009

Как вы, ребята, избегаете конфликтов ключевых слов на вашем языке?

Например, я создаю класс (VB 2008) для хранения всех переменных конфигурации для некоторых отчетов, которые мы генерируем. Естественно, одной из переменных является «Дата». И, конечно, вы не можете иметь ничего похожего на ключевое слово. В VB 2008 у вас есть возможность заключить противоречивое слово в [] и исправить его, но я всегда считал это хаком. Какие-либо предложения? Как ваши имена, чтобы обойти общие ключевые слова?

Код для визуализации ...

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 

Ответы [ 9 ]

5 голосов
/ 17 июля 2009

Вероятно, подумаете о более конкретной природе переменной?

В вашем примере «Дата» может быть «Дата создания» или «Дата публикации» или что-то еще. Если вы находите имена переменных слишком тривиальными, возможно, вы упрощаете (или даже запутываете) свой код. Помогите своим коллегам, создавая четкие, но краткие имена переменных.

1 голос
/ 18 июля 2009

В .NET целесообразно рассматривать Спецификацию общего языка (CLS) как наименьший общий знаменатель, который вам следует учитывать. Это задокументировано в ECMA-335 «Общий язык» «Инфраструктура (CLI) Разделы с I по VI». Вот что конкретно говорится об именах; примечание к правилу CLS № 4 (8.5.1 «Действительные имена»):

CLS (потребитель): не нужно использовать типы, которые нарушают правило 4 CLS, но должен иметь механизм, разрешающий доступ к именованным элементам, использующим в качестве имени одно из своих ключевых слов .

Так что нет, на самом деле это не хак, а определенное правило. Причина этого заключается в том, что, поскольку .NET расширяемо для целевых языков, вы никогда не сможете избежать столкновения имен. Если вы охватываете C #, есть VB. Если вы охватываете C # и VB, есть C ++ / CLI. Если вы охватите все это, есть F # и Delphi Prism. И так далее. Следовательно, CLS обязывает языки обеспечивать способ избежать их ключевых слов в качестве идентификаторов; и все языки, которые я перечислил, предоставляют некоторый способ сделать это (и, следовательно, являются совместимыми потребителями CLS).

В общем, все еще считается хорошим способом избегать столкновений с неконтекстными ключевыми словами C # или VB, главным образом потому, что эти два языка наиболее популярны с очень большим запасом. Например, это причина того, что это HashSet, а не просто Set - последнее является ключевым словом VB. Полные списки:

1 голос
/ 18 июля 2009

неправильно написали имена ваших переменных!

1 голос
/ 18 июля 2009

Не смотрите на [Date] как на хак; если ваша собственность представляет дату, она должна называться Date. Используйте имеющиеся у вас инструменты, чтобы выполнить работу. Лично я считаю, что свойства с именами, которые они делают только для того, чтобы обойти такие конфликты, скорее хак, так как вы будете иметь дело с этим каждый раз, когда используете это свойство.

0 голосов
/ 20 июля 2009

Это один вопрос, в котором Perl полностью уклоняется от вопроса.

Переменные всегда имеют одну из $%@*&, единственные вещи, которые могут конфликтовать, это Globs / Handles и подпрограммы.

Даже это не составляет большой проблемы, потому что Globs / Handles больше не используются.

Подпрограммы и ключевые слова практически одинаковы в Perl. Если вам нужно получить встроенную подпрограмму / ключевое слово, вы можете получить ее, добавив CORE::, например CORE::dump.

Действительно, я думаю, что единственные ключевые слова, с которыми у вас возникнут проблемы, - это sub, my, local и 'наш', потому что эти ключевые слова анализируются очень рано в синтаксическом анализаторе. Обратите внимание, что вы все еще можете создать подпрограмму с этими именами, она просто не будет работать без указания полного имени, или из благословенной ссылки, или с символической ссылкой.

{
  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');

Выход:

'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
0 голосов
/ 18 июля 2009

«Дата_» или «_Date».

0 голосов
/ 18 июля 2009

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

В моем случае я проклинаю тот факт, что C имеет команду 'index'.

0 голосов
/ 17 июля 2009

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

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

0 голосов
/ 17 июля 2009

В большинстве языков есть что-то, чтобы избежать любых зарезервированных слов. В C # есть @, так что вы можете использовать @class в качестве имени аргумента (чему обучаются приемные MVC).

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...