Почему языки программирования не позволяют пробелы в идентификаторах?

Ознакомьтесь с классикой Страуструпа Обобщающая перегрузка для C ++ 2000 .

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

Я не думаю, что в этом есть реальная причина.

Такое изменение в лучшем случае сделало бы язык двусмысленным. Например, в языке, подобном C99:

if not foo(int x) {
    ...
}

эквивалентно:

1. Определение функции foo , которая возвращает значение типа , если не :

   , если не foo (int x) {
    ...
   }
   

2. Вызов функции notfoo с переменной с именем intx :

    if notfoo (intx) {
    ...
   }
   

3. Инвертированный вызов функции с именем foo (с не C99, что означает ! ):

    if not foo (intx) {
    ...
   }
   

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

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

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

Мы просто не можем ждать еще 50 лет, прежде чем наш код снова заработает. : -)

(И то, что говорили все остальные, конечно. В английском языке мы используем пробелы и знаки препинания для разделения слов. То же верно и для компьютерных языков, за исключением того, что компьютерные парсеры определяют «слова» в несколько ином смысле )

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

  "proc" filter = ("proc" ("int") "bool" p, "list" l) "list":
     "if" l "is" "nil" "then" "nil"
     "elif" p(hd(l)) "then" cons(hd(l), filter(p,tl(l)))
     "else" filter(p, tl(l))
     "fi";

Кроме того, FORTRAN (заглавная форма означает F77 или более раннюю версию) был более или менее нечувствителен к пробелам. Таким образом, это можно было бы записать:

  799 S = FLO AT F (I A+I B+I C) / 2 . 0
      A  R E  A = SQ R T ( S *(S - F L O ATF(IA)) * (S - FLOATF(IB)) *
     +     (S - F LOA TF (I C)))

который синтаксически идентичен

  799 S = FLOATF (IA + IB + IC) / 2.0
      AREA = SQRT( S * (S - FLOATF(IA)) * (S - FLOATF(IB)) *
     +     (S - FLOATF(IC)))

. С такой историей злоупотреблений, зачем затруднять синтаксический анализ для людей? Не говоря уже об усложнении компьютерного парсинга.

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

Использование пробела в качестве части идентификатора делает синтаксический анализ действительно непонятным (это синтаксическое пространство или идентификатор?), Но такое же поведение «естественного чтения» достигается с помощью аргументов ключевого слова. object.save (data: something, atomically: true)

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