Ключевые слова без учета регистра на языке [закрыто]

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

Лично мне не нравится эта идея, но в моей команде мало кто склоняется к ней, говоря, что она порадует конечного пользователя! Приведены примеры языков, таких как FORTRAN, BASIC, SQL, в которых говорится, что они не чувствительны к регистру.

Это хорошая идея?

Спросите себя, кто является конечным пользователем. Если он предназначен для написания кем-то, имеющим опыт программирования на C или Javscript или опыт работы с ИТ в Unix, то чувствительность к регистру, вероятно, правильное, потому что именно этого ожидает пользователь. Но для большинства конечных пользователей, даже для опытных пользователей, это будет сбивать с толку.

VB / VBA / VBScript нечувствительны к регистру, и это решение было принято, чтобы позволить непрограммистам легко освоить язык. Формулы Excel, не только скрипты, но настолько близкие, как многие пользователи, не чувствительны к регистру. В большинстве случаев при выборе кейса текст выглядит более или менее профессионально и отточенно, но сам кейс не изменит семантического значения слов. Вот почему я полагаю, что не разработчики будут смущены чувствительным к регистру языком сценариев.

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

Вы должны решить, основываясь на пользовательском опыте, который вы хотите представить, а не на том, насколько легко или сложно это реализовать.

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

В данном случае SQL не чувствителен к регистру. Это делает его очень простым в использовании в интерактивном режиме.

Другой способ смотреть на это будет ли когда - нибудь разница между keywordи Keywordна вашем языке, и эта разница будет значимой для пользователя? Для языка сценариев я бы сказал, что ответ «нет».

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

Когда-то казалось очевидным сделать языки нечувствительными к регистру. Это связано с тем, что строчные буквы были доступны не для всех вычислительных систем и их устройств ввода-вывода (клавиатуры, принтеры и устройства отображения). Реализации языка программирования должны были принимать программы, написанные в верхнем регистре, так как только это могло быть отображено или напечатано. И для этого они должны были быть нечувствительными к регистру, потому что принимать заглавные буквы и быть чувствительными к регистру в то же время означает отклонять строчные. Строчные буквы были тем, чего хотели программисты, но не всегда могли. Никто действительно не хотел работать с программами, которые кричали в верхнем регистре; это было просто аппаратное ограничение.

Какое-то время было обычным делом даже складывать чемоданы в терминалах. Если терминал мог отображать только верхний регистр, но вы должны были войти в вычислительную систему, поддерживающую верхний и нижний регистр, терминал перевернул бы нижний регистр в верхний регистр. Думаешь, это было так давно? «Как и Apple II, у Apple II Plus не было строчной функциональности». (http://en.wikipedia.org/wiki/Apple_II_Plus) Когда пользователи ранних компьютеров Apple набирали номер BBS со смешанным содержимым, эмулятор терминала (или хост) должен был свернуть все это в верхний регистр. В те дни сообщения, написанные заглавными буквами, были обычным делом на досках объявлений. Эта функциональность все еще присутствует в Unix-подобных операционных системах, таких как ядро ​​Linux. Например, введите stty olcucв командной строке приглашение.Дисциплина строки Unix tty может отображать нижний регистр в верхний регистр при выводе, и она может отображать верхний регистр в нижний регистр при вводе. Это позволяет вам работать на языке программирования в нижнем регистре, на терминале, который не имеет строчных букв.

Нечувствительность к регистру - устаревшая концепция ушедшей компьютерной эры, которая не очень хорошо работает в современном мире интернационализированных вычислений. Вы распространяете это на другие языки? Как насчет французского: вы считаете È и è эквивалентными? Или японский? Считаете ли вы хирагана и катакана просто случаями, чтобы フ フ イ ル и ふ ぁ い る были одним и тем же идентификатором? Поддержка такой глупости значительно усложнит ваш лексический анализатор, который должен иметь карты эквивалентности регистра для всего пространства Юникода.

Обратите внимание, что математика чувствительна к регистру. Например, сигма в верхнем регистре может обозначать суммирование, тогда как сигма в нижнем регистре обозначает что-то еще, например, стандартное отклонение. Это может произойти в той же формуле, не создавая никаких трудностей. (Будет ли язык программирования делать Σ и σ эквивалентными?)

Английская орфография чувствительна. Например, многие собственные существительные соответствуют обычным существительным или даже другим частям речи. «май» - это глагол, но «май» - это месяц или имя женщины. Более того, если аббревиатура или аббревиатура написана в нижнем регистре, это может сбить с толку. SAT означает «схоластический тест на способность», тогда как «sat» - это причастие «sit» в прошлом. Интеллигентные люди обращают внимание на детали и правильно пишут.

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

Что, если ваш язык когда-либо используется в качестве цели генерации кода для перевода кода на другой язык, и этот другой язык чувствителен к регистру? Вам придется каким-то образом преобразовать все имена, чтобы уловить различие. (Так что утверждать, что это не техническое решение, а только вопрос эмоциональных предпочтений целевой аудитории, смешно.)

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

Common Lisp нашел идеальный подход: имена символов чувствительны к регистру, но когда токены читаются, они складываются в верхний регистр. Это означает , что маркеры foo, fOO, FOOи Fooвсе обозначают тот же символ: символ, имя которого хранится в виде строки символов "FOO". Кроме того, это поведение является только конфигурацией таблицы чтения по умолчанию. Читатель может сложить буквы в верхний регистр, в нижний регистр, перевернуть регистр или сохранить его. Последние два варианта дают начало чувствительному к регистру диалекту. Таким образом, пользователи имеют максимальную гибкость.

Реальным определяющим фактором является то, как часто вы захотите иметь несколько вещей с одним и тем же именем. Нечувствительность к регистру работает в SQL, потому что не часто вам нужен столбец с именем SELECT. Это будет раздражать в Java, потому что каждая другая строка выглядит так Object object = new Object(), где вы хотите, чтобы одно и то же имя ссылалось на класс, экземпляр и конструктор.

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

Однажды я создал язык правил, в котором идентификаторы не только не чувствительны к регистру, но и нечувствительны к пробелам. Я также позволил создавать псевдонимы, которые ссылаются на один и тот же идентификатор. Например, ProgrammersStackExchange, стек программирования программистов и PSE - все они разрешены в один и тот же символ и могут использоваться взаимозаменяемо.

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

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

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

ATypo = 42; 

в отличие от

Atypo = 42; 

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

Приведены примеры языков, таких как FORTRAN, BASIC, SQL, в которых говорится, что они не чувствительны к регистру.

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

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

Чувствительность к регистру считается вредной.

Жизнь не чувствительна к регистру, и ни пользователи, ни программисты.

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

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

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

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

Более важным является именование и структурные соглашения, которые программист должен хранить в своем коде, и никакой компилятор или парсер не проверяет его за него. Если вы придерживаетесь каких-то правил, вы легко узнаете правильное имя (вы не будете думать, назвали ли вы переменную checkOut или CheckOut), и ваш код, вероятно, будет чувствителен к регистру и его будет легче читать.

Не следует использовать CheckOut и checkOut и checkout, а также cHeCkOuT и CHECKOUT в одном и том же значении. Это ухудшит читабельность и сделает понимание такого рода кода более болезненным (но есть и худшее, что можно сделать, чтобы нарушить читабельность кода).

Если вы используете какие-то правила, вы сразу увидите, например:

CheckOut.getInstance () - это статический метод класса с именем checkOut.calculate () - это метод объекта, который хранится в переменной или в открытом поле с именем _checkOut.calculate () - это метод объекта, который хранится в закрытом поле с именем CHECKOUT - это окончательное статическое или постоянное поле / переменная

без проверки некоторых других файлов или частей файла. Это делает чтение кода быстрее.

Я вижу довольно много разработчиков, использующих подобные правила - на языках, которые я часто использую: Java, PHP, Action Script, JavaScript, C ++.

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

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

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

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

Это на самом деле является частью философии вождения C и UNIX: если у вас есть выбор между плохим решением, которое легко внедрить, и хорошим решением, которое труднее реализовать, выберите плохое решение и перекладывайте бремя работы над вашим беспорядком на Пользователь. Это может звучать как snark, но это абсолютно верно. Он известен как принцип «чем хуже, тем лучше», и за последние несколько десятилетий он несет прямую ответственность за ущерб в миллиарды долларов из-за того, что С и С ++ слишком упрощают написание проблемных и небезопасных программ.

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

• Во-первых, особенно если вы создаете язык сценариев, простую опечатку, в которой вы называете что-то «myObject» в одном месте и «MyObject» в другом, где вы явно ссылаетесь на один и тот же объект, но просто немного несовместимы с заглавными буквами , не превращается в ошибку во время выполнения. (Это печально известно как главная проблема в языках сценариев, которые ошибаются, например, в Python.)
• Во-вторых, отсутствие чувствительности к регистру означает, что к чувствительности к регистру нельзя злоупотреблять , если одно и то же слово относится к двум разным вещам в одной и той же области просто путем изменения заглавных букв. Если вам когда-либо приходилось работать с кодом Windows в среде C и сталкиваться с такими уродливыми объявлениями, как HWND hwnd;, вы точно поймете, о чем я говорю. Люди, которые пишут так, должны быть убиты и расстреляны, а то, что язык нечувствителен к регистру, не позволит злоупотреблению чувствительностью к регистру проникнуть в ваш код.

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

Я не могу поверить, что кто-то сказал: «Чувствительность к регистру облегчает чтение кода».

Это, безусловно, нет! Я посмотрел через плечо коллеги на переменные, которые назывались Company и company (общедоступная переменная Company, совпадающая частная переменная company), и его выбор шрифта и цвета делает невероятно трудным различие между ними - даже когда они рядом.

Правильное утверждение должно быть «смешанный регистр облегчает чтение кода». Это гораздо более очевидная истина - например, переменные с именем CompanyName и CompanyAddress, а не с названием компании. Но ни один из известных мне языков не позволяет использовать только имена переменных в нижнем регистре.

Самая безумная конвенция, о которой я знаю, это «открытая прописная, закрытая». Это просто напрашивается на неприятности!

Мой подход к ошибкам - «лучше, если что-то не получится шумно и как можно скорее, а не тихо, но, похоже, будет успешно». И не раньше, чем время компиляции.

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

Гораздо лучше использовать соглашение, в котором частная переменная имеет суффикс - например, открытая переменная Company, закрытая переменная CompanyP. Никто не собирается случайно смешивать два, и они появляются вместе в intellisense.

Это контрастирует с возражением людей к венгерской нотации, где префикс частной переменной pCompany не будет в хорошем месте в intellisesne.

Это соглашение имеет все преимущества ужасного соглашения в верхнем / нижнем регистре и ни одного из его недостатков.

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

Сделайте вещи, с которыми вы работаете, четко и очевидно отличными друг от друга, даже если они связаны между собой !!

Вы не должны вводить нечувствительность к регистру без веской причины для этого. Например, иметь дело со сравнениями случаев с Unicode может быть сукой. Чувствительность к регистру (или его отсутствие) старых языков не имеет значения, так как их потребности были очень разными.

Программисты в эту эпоху ожидают чувствительности к регистру.

Чувствительность к регистру делает код более читабельным и облегчает программирование.

• Люди находят правильное использование смешанного падежа легче для чтения .

• Это позволяет / поощряет CamelCase таким образом, чтобы одно и то же слово в другом регистре могло ссылаться на связанные вещи: Car car; Таким образом, именованная переменная carсоздается типа Car.

• ALL_CAPS_WITH_UNDERSCORES указывает константы по соглашению во многих языках

• all_lower_with_underscores может использоваться для переменных-членов или чего-то еще.

• Все современные инструменты программирования (управление исходным кодом, редакторы, diff, grep и т. Д.) Разработаны с учетом регистра. У вас всегда будут проблемы с инструментами, которые программисты считают само собой разумеющимся, если вы сделаете язык без учета регистра.

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

• А как насчет неанглийских символов? Вы решаете сейчас никогда не поддерживать коптский, китайский и хинди? Я настоятельно рекомендую установить для вашего языка все по умолчанию на UTF-8, и это поддерживает некоторые языки, в которых есть символы без эквивалента в верхнем или нижнем регистре. Вы не будете использовать эти символы в своих ключевых словах, но когда вы начнете отключать чувствительность к регистру в различных инструментах (например, для поиска вещей в файлах), вы столкнетесь с некоторыми сюрреалистическими и, вероятно, неприятными впечатлениями.

В чем выгода? 3 языка, которые вы упоминаете, относятся к 1970-м или ранее. Ни один современный язык не делает это.

С другой стороны, все, что действительно делает конечного пользователя счастливым, приносит немного света в мир. Если это действительно повлияет на счастье пользователя, то вам придется это сделать.

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