Почему имена переменных не могут начинаться с цифр?

Хорошо подумайте об этом:

int 2d = 42;
double a = 2d;

Что такое? 2.0? или 42?

Подсказка: если вы не поняли, d после числа означает, что число перед ним является двойным литералом

Потому что тогда строка цифр будет как действительным идентификатором, так и действительным числом.

int 17 = 497;
int 42 = 6 * 9;
String 1111 = "Totally text";

Компиляторы / парсеры / лексические анализаторы были для меня давным-давно, но я думаю, что помню, как было трудно однозначно определить, представляет ли числовой символ в модуле компиляции литерал или идентификатор.

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

Это восходит к прошлому - до специальных обозначений для обозначения памяти или числовой базы.

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

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

Существует также стилистический подтекст: идентификаторы должны быть мнемоникой, поэтому слова запоминать намного легче, чем числа. Когда писалось множество оригинальных языков, задающих стили на следующие несколько десятилетий, они не думали о замене «2» на «to».

Я думаю, что простой ответ - может, ограничение основано на языке. В C++ и многих других это невозможно, потому что язык не поддерживает это. Это не разрешено правилами.

Этот вопрос похож на вопрос, почему король не может перемещать четыре клетки за раз в шахматах? Это потому, что в шахматах это недопустимый ход. Может это в другой игре точно. Это просто зависит от правил игры.

Использование цифры в начале имени переменной значительно усложняет проверку ошибок во время компиляции или интерпретации.

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

Насколько я себя помню (около 40 лет), я не думаю, что когда-либо использовал язык, который позволял бы использовать цифру в начале имен переменных. Я уверен, что это было сделано хоть раз. Может быть, кто-то здесь действительно где-то видел это.

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

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

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

В качестве примера довольно простого языка шаблонов HTML, который позволяет переменным начинаться с цифр и иметь встроенные пробелы, посмотрите Qompose.

C++ не может иметь этого, потому что разработчики языка сделали это правилом. Если бы вы создали свой собственный язык, вы, конечно, могли бы это разрешить, но вы, вероятно, столкнетесь с теми же проблемами, что и они, и решите не позволять этого. Примеры имен переменных, которые могут вызвать проблемы:

0x, 2d, 5555

Вероятно, потому, что так человеку легче определить, число это или идентификатор, а также в силу традиции. Наличие идентификаторов, которые могут начинаться с цифры, не сильно усложнит лексическое сканирование.

Не во всех языках есть запрещенные идентификаторы, начинающиеся с цифры. В Forth они могли быть числами, а маленькие целые числа обычно определялись как слова Forth (по сути, идентификаторы), поскольку было быстрее читать «2» как процедуру для помещения 2 в стек, чем распознавать «2» как число. чье значение было 2. (При обработке ввода от программатора или блока диска система Forth разделяла ввод по пробелам. Она пыталась найти токен в словаре, чтобы увидеть, было ли это определенное слово, и в противном случае попытался бы преобразовать его в число, а в противном случае - пометил бы ошибку.)

Предположим, вы разрешили имена символов начинаться с цифр. Теперь предположим, что вы хотите назвать переменную 12345foobar. Как бы вы отличили это от 12345? На самом деле это не так уж сложно сделать с регулярным выражением. Проблема на самом деле заключается в производительности. Я не могу объяснить, почему это так подробно, но, по сути, все сводится к тому факту, что для отличия 12345foobar от 12345 требуется возврат. Это делает регулярное выражение недетерминированным.

Есть гораздо лучшее объяснение этому здесь.

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

Я думаю, что отчасти проблема связана с числовыми литералами, такими как 0xdeadbeef, которые затрудняют создание легко запоминающихся правил для идентификаторов, которые могут начинаться с цифры. Один из способов сделать это - разрешить все, что соответствует [A-Za-z _] +, но НЕ является ключевым словом или числовым литералом. Проблема в том, что это приведет к тому, что будут разрешены такие странные вещи, как 0xdeadpork, но не 0xdeadbeef. В конце концов, я считаю, что мы должны быть справедливыми по отношению ко всему мясу: P.

Помню, когда я впервые изучал C, я чувствовал, что правила для имен переменных были произвольными и ограничительными. Хуже всего то, что их было трудно запомнить, поэтому я отказался от попыток их выучить. Я просто делал то, что считал правильным, и это сработало очень хорошо. Теперь, когда я узнал намного больше, это не кажется таким уж плохим, и я наконец нашел время, чтобы выучить это правильно.

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

Разве не Дайкстра сказал, что «самый важный аспект любого инструмента - это его влияние на пользователя»?

Потому что, если вы разрешили ключевому слову и идентификатору начинаться с числовых символов, лексер (часть компилятора) не мог легко отличить начало числового литерала от ключевого слова, не становясь намного сложнее (и медленнее).

Сейчас это конвенция, но начиналась она как техническое требование.

Раньше синтаксические анализаторы языков, таких как FORTRAN или BASIC, не требовали использования пробелов. Итак, в основном следующие идентичны:

10 V1=100
20 PRINT V1

и

10V1=100
20PRINTV1

Теперь предположим, что числовые префиксы разрешены. Как бы вы это интерпретировали?

101V=100

как

10 1V = 100

или как

101 V = 100

или как

1 01V = 100

Итак, это было объявлено незаконным.

Ограничение произвольное. В различных Лиспах имена символов могут начинаться с цифр.

Первоначально это было просто потому, что легче запомнить (вы можете придать ему больше смысла) имена переменных как строки, а не числа, хотя числа могут быть включены в строку, чтобы улучшить значение строки или разрешить использование того же имени переменной, но обозначить его как имеющее отдельный, но близкий смысл или контекст. Например, loop1, loop2 и т. д. Всегда будут сообщать вам, что вы находитесь в цикле и / или цикл 2 был циклом внутри цикла loop1. Что бы вы предпочли (имеет большее значение) в качестве переменной: адрес или 1121298? Что легче запомнить? Однако, если в языке используется что-то для обозначения того, что это не просто текст или числа (например, $ в адресе $), это действительно не должно иметь значения, поскольку это сообщит компилятору, что то, что следует далее, следует рассматривать как переменную ( в таком случае). В любом случае все сводится к тому, что разработчики языка хотят использовать в качестве правил для своего языка.

Имена переменных не могут начинаться с цифры, потому что это может вызвать некоторые проблемы, как показано ниже:

int a = 2;
int 2 = 5;
int c = 2 * a; 

каково значение c? равно 4 или 10!

другой пример:

float 5 = 25;
float b = 5.5;

это первая цифра 5 или объект (оператор.) Аналогичная проблема со вторым 5.

Может быть, есть еще какие-то причины. Итак, мы не должны использовать какие-либо цифры в начале имени переменной.

компилятору легко идентифицировать переменную, используя ASCII в ячейке памяти, а не по номеру.

Потому что при лексическом анализе во время компиляции исключается возврат с возвратом. Такая переменная, как:

Apple;

компилятор сразу узнает, что это идентификатор, когда он встретит букву «А».

Однако такая переменная, как:

123apple;

компилятор не сможет решить, является ли это числом или идентификатором, пока он не достигнет «a», и в результате ему потребуется возврат с возвратом.

COBOL позволяет переменным начинаться с цифры.

Переменная может рассматриваться как значение также во время компиляции компилятором. поэтому значение может вызывать значение снова и снова рекурсивно

На этапе лексического анализа при компиляции фрагмента кода исключается возврат с возвратом.. Переменная вроде Apple; , компилятор сразу узнает свой идентификатор, когда встретит букву «A» на этапе лексического анализа. Однако такая переменная, как 123apple; , компилятор не сможет решить, является ли это числом или идентификатором, пока он не достигнет «a» и ему не потребуется выполнить обратный поиск, чтобы перейти на фазу лексического анализа, чтобы определить, что это переменная. Но в компиляторе это не поддерживается.

Справка

Компилятор имеет следующие 7 этапов:

1. Лексический анализ
2. Синтаксический анализ
3. Семантический анализ
4. Генерация промежуточного кода
5. Оптимизация кода
6. Генерация кода
7. Таблица символов

На этапе лексического анализа при компиляции фрагмента кода исключается обратный поиск. Такая переменная, как Apple, компилятор узнает ее идентификатор сразу же, когда он встретит букву «A» на этапе лексического анализа. Однако для такой переменной, как 123apple, компилятор не сможет решить, является ли это числом или идентификатором, пока он не достигнет «a», и ему потребуется возврат с возвратом, чтобы перейти на фазу лексического анализа, чтобы определить, что это переменная. Но в компиляторе это не поддерживается.

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

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

let 1 = "Привет, мир!" печать (1) печать (1)

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