Почему идентификатор не может начинаться с числа?

Ответ 1

Как правило, вы устанавливаете такое ограничение по двум причинам:

• Это боль для анализа в электронном виде.
• Это боль для людей, чтобы разобрать.

Рассмотрим следующий фрагмент кода:

int d, -d;
d = 3;
-d = 2;
d = -d;

Если -d является юридическим идентификатором, то какое значение имеет d в конце? -3 или 2? Это двусмысленно.

Также рассмотрим:

int 2e10f, f;
2e10f = 20;
f = 2e10f;

Какое значение имеет значение f в конце? Это также неоднозначно.

Кроме того, это боль, которую нужно читать в любом случае. Если кто-то объявляет 2ex10, это опечатка для двух миллионов или имя переменной?

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

Ответ 2

Это потому, что раздел 3.8 Спецификации языка Java говорит так.

Идентификатор является неограниченной длиной последовательность букв Java и Java цифры, первая из которых должна быть Письмо Java. Идентификатор не может иметь одно и то же правописание (символ Юникод последовательность) в качестве ключевого слова (§3.9), boolean буквальный (§3.10.3), или нулевой литерал (§3.10.7).

Что касается того, почему было принято это решение: возможно, потому, что это упрощает синтаксический анализ, избегает двусмысленной грамматики, позволяет вводить специальный синтаксис в более поздней версии языка и/или по историческим причинам (т.е. потому что большинство других языков имеют одинаковые ограничения)). Обратите внимание, что пример примеров с -d особенно ясен:

int -d = 7;
System.out.println("Some number: " + (8 + -d));

Является ли минус первой частью идентификатора или унарным минусом?

Кроме того, если бы у вас были как -d, так и d в качестве переменных, это было бы полностью двусмысленно:

int -d = 7;
int d = 2;
System.out.println("Some number: " + (8 + -d));

Является ли результат 15 или 6?

Ответ 3

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

Ответ 4

Такие вещи не допускаются практически на любом языке (я не могу думать об этом прямо сейчас), в основном для предотвращения путаницы.

Ваш пример -d - отличный пример. Как компилятор знает, если вы имели в виду "переменную с именем -d" или "отрицательный номер в переменной d"? Поскольку он не может сказать (или, что еще хуже, может быть, вы не могли быть уверены, что произойдет, когда вы наберете это, не читая остальную часть файла), это не разрешено.

Пример 7g - это одно и то же. Вы можете указать числа как определенные базы или типы, добавив буквы в конец. Число 8357 является int в Java, где 8357L является длинным (поскольку на конце есть "L" ). Если переменные могут начинаться с цифр, бывают случаи, когда вы не можете определить, должно ли оно быть именем переменной или просто литералом.

Я бы предположил, что остальные, которые вы указали, имеют сходные причины, некоторые из которых могут быть историческими (т.е. C не может сделать это по причине X, а Java имеет вид C, поэтому они сохранили правило).

На практике это почти никогда не проблема. Очень редко вы находите ситуацию, когда такие вещи раздражают. Тот, с которым вы столкнетесь больше всего, это переменные, начинающиеся с цифр, но вы всегда можете просто их прописать (т.е. OneThing, twoThing, threeThing и т.д.).

Ответ 5

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

Парсеры обычно записываются, чтобы сначала разбить исходный текст на "токены". Идентификатор, начинающийся с числа, выглядит как число. Кроме того, 5e3, является допустимым числом (5000.0) на некоторых языках.

Между тем: и. обозначаются как операторы. В некоторых контекстах идентификатор, начинающийся с одного из них, приведет к двусмысленному коду. И так далее.

Ответ 6

Каждый язык должен определить, что является допустимым символом для идентификатора, а что нет. Частью рассмотрения будет простота разбора, часть должна состоять в том, чтобы избежать двусмысленности (другими словами, даже идеальный алгоритм синтаксического анализа не мог быть уверенным все время), часть будет предпочтительнее языкового дизайна (в случае с аналогией Java с C, С++), а некоторые просто будут произвольными.

Дело в том, что это должно быть что-то, поэтому это то, что есть.

Ответ 7

Например, не так много раз мы хотим иметь объекты с этими именами?

2ndInning
3rdBase
4thDim
7thDay

Но представьте, когда кто-то попытается иметь переменную с именем 666:

int 666 = 777;
float 666F = 777F;
char 0xFF = 0xFF;
int a = 666; // is it 666 the variable or the literal value?
float b = 666F // is it 666F the variable or the literal value?

Возможно, одним из способов, который мы могли бы подумать, является то, что переменные, начинающиеся с цифры, должны заканчиваться алфавитом - до тех пор, пока он не начинается с 0x и заканчивается буквой, используемой как шестнадцатеричная цифра, или он не заканчивается символами, такими как L или F, и т.д. и т.д.

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

В моих усилиях, использующих лексеры и regexp для анализа журналов данных и потоков данных для вставки в базы данных, я не обнаружил, что ключевое слово или переменная, начинающаяся с цифры, затруднит анализ - так долго есть короткий путь, чтобы устранить двусмысленность.

Следовательно, это не так, как облегчение для компилятора, но для программиста.