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


31

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

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

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


4
Ну, Visual Basic, как правило, не чувствителен к регистру, это отвечает на ваш вопрос? ; P
Яннис


3
Обратите внимание, что очень трудно сделать идентификаторы нечувствительными к регистру, если вы не ограничите пользователей набором символов ASCII.
Саймон Рихтер

2
@MainMa: C ++ по крайней мере не напрямую. Это позволяет реализовать определенные символы в идентификаторе, но то , что гарантируется только a-zA-Z, 0-9( за исключением самого начала) и _.
Xeo

2
VB6 на самом деле использует своего рода гибридный подход: вы можете писать ключевые слова и идентификаторы любым удобным для вас способом, и среда IDE немедленно преобразует их в сохраненный способ. (Вы даже можете написать «endif», и он будет преобразован в «End If».)
Феликс Домбек

Ответы:


42

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

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

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


Подумайте о том, какие файловые системы чувствительны к регистру, прежде чем смотреть на языки программирования. FAT / NTFS для Windows и HFS + для MacOS X не чувствительны к регистру, а UFS / NFS для Unix чувствительны к регистру. Опытным пользователям нравится различать файлы / переменные по крошечным различиям, в то время как большинство пользователей предпочитают делать вещи более интуитивно понятными. Как говорит Авнер, разница в выборе продукта.
Михаил Шопсин

4
Так как это язык сценариев, он не представляет сложности - нечувствительность к регистру - это путь. Зачем быть чувствительным к регистру? Если ответ «быть похожим на C и Java», это действительно хорошая причина?
Бен

15
@Ben Python, Ruby, bash, Lua и Perl являются примерами очень популярных языков сценариев, чувствительных к регистру. Нечувствительные к регистру языки включают в себя корпоративные языки, такие как Delphi и SQL (и COBOL IIRC, если вы считаете это). Почему для языков сценариев нет ничего сложного, и почему дизайнеры крупнейших в мире языков сценариев не согласны?

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

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

16

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

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

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

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


3
+1 за "будет ли эта разница значимой для пользователя". Пользователь важнее всего.
Бен

Почему SQL легче использовать в интерактивном режиме из-за нечувствительности к регистру? Это потому, что вы можете случайно включить Caps Lock и не заметить?
Каз

@Kaz - Довольно.
ChrisF

11

Языки программирования должны учитывать регистр, точка. Люди могут легко приспособиться к этому: им просто нужно помнить, что они работают в основном в нижнем регистре, и следить за идентификаторами со смешанным регистром или заглавными буквами в существующих 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". Кроме того, это поведение является только конфигурацией таблицы чтения по умолчанию. Читатель может сложить буквы в верхний регистр, в нижний регистр, перевернуть регистр или сохранить его. Последние два варианта дают начало чувствительному к регистру диалекту. Таким образом, пользователи имеют максимальную гибкость.


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

Хорошо, приготовьтесь к тому, чтобы ваша маленькая голова взорвалась, потому что я не думаю, что культуры других людей глупы (за некоторыми исключениями, в отношении текущих событий в мире), но в то же время я думаю, что совершенно глупо относиться к フ ァ イ ル иる ぁ い る как тот же идентификатор в языке программирования.
Каз

@ А вы знаете, о каких культурах говорилось? Если бы вы знали, о чем говорил Каз, вы бы не назвали его глупым.
Дэвид Кауден

1
@DavidCowden, я ни в коем случае не назвал Каз глупым. Я согласен, что всегда следует использовать один и тот же случай везде, где используется идентификатор. Разница в кана более значительна, чем разница в регистре, так же как разница в акценте более значительна, чем разница в регистре. Однако так же, как глупо иметь два идентификатора, которые отличаются только регистром, также глупо иметь два идентификатора, которые различаются только по кане или по акценту. Более разумно запретить идентификаторы, различающиеся только по кане или акценту, чем относиться к ним одинаково, но бессмысленно относиться к ним как к разным.
Бен

Если вы запрещаете идентификаторы, которые отличаются только регистром, акцентом или кана или чем-то еще, вы молчаливо признаете, что они одинаковы (но только настаивают на последовательности). Лучше не изгонять такие вещи, а оставлять их на усмотрение пользователей. Лучшей идеей было бы иметь декларативную систему, посредством которой программа может утверждать это fooи Fooдолжна рассматриваться как синонимы или как отдельные. Без такой декларации является ошибкой для обоих из них. А поскольку декларация не распространяется на FOO, то FOOвсе равно запрещено; это должно быть добавлено.
Каз

6

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

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

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

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


Я не думаю, что желание повторно использовать ключевые слова для имен является проблемой. SQL, Visual Basic и C # (первые два без учета регистра и последний с учетом регистра) решают эту проблему, позволяя заключить в кавычки идентификаторы: "double quotes"(или [brackets]в MS SQL) в SQL, [brackets]в VB.net и @atsignв C #.
Random832

«как часто вы захотите иметь несколько вещей с одним и тем же именем». Нечувствительность к регистру означает, что вы должны добавить некоторые накладные расходы для устранения неоднозначности имен, которые в противном случае рассматривались бы в каждом конкретном случае (например, m в качестве префикса для элемента 'member', чтобы отличить, скажем, от имени свойства unprefix).
nwahmaet

Почему вы бы назвали объект объекта? Это просто напрашивается на неприятности.
Бен

@Ben, предположим, что вы реализуете контейнерный объект, что еще вы собираетесь вызывать параметр для вашего метода add?
Уинстон Эверт

@WinstonEwert, я бы назвал это o. Неважно, как вы это называете, так как это просто имя параметра. Пока это не оскорбительно или незаконно, или может вызвать путаницу .
Бен

5

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


Хороший вопрос, но не ответ.

@delnan: возможно, не такой хороший ответ, как ответ Авнера Шахар-Каштана (которому я дал +1), но, вероятно, полезный для ОП.
Док Браун

3
Да, полезно как комментарий;)

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

Нет, тогда это будет второстепенный вопрос, который вряд ли отвечает на вопрос, сформулированный как ответ. ИМХО.

4

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

ATypo = 42; 

в отличие от

Atypo = 42; 

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


2
ИМХО, это облегчает чтение. В конце концов, когда вы начинаете предложение, вы пишете с заглавной буквы первое слово, но вы не меняете его значение. То же самое должно быть для кода!
NWS

2
@delnan - вы хотели читабельности, он использует тот же алфавит, зачем менять значение, когда вы меняете регистр?
NWS

1
@delnan, согласно Верховному суду Соединенных Штатов Америки, компьютерные языки являются выразительным языком, предназначенным для понимания как компьютерами, так и людьми (когда решение о том, что компьютерный код защищен первой поправкой). Они не английские, но они являются языком, и выражение «BOB» отличается от «bob», отличается от «Bob» идиотично на любом языке, предназначенном для использования людьми. Да, мы можем научиться справляться с этим, но это не оправдание.
Бен

2
@Ben Позвольте мне привести аналогию. Математическая нотация, в отличие от языков программирования, исключительно для людей. Обычный аргумент нечувствительности к регистру, являющийся историческим артефактом древних компьютеров, здесь не применим. Тем не менее, я сомневаюсь, что любой математик будет утверждать, что aи Aдолжны быть взаимозаменяемыми. Они случаются последовательно, без исключений. Например, в некоторых контекстах заглавные буквы используются для наборов, в то время как строчные буквы являются элементами набора. Другой пример встречается в электротехнике: строчные буквы зависят от времени, а верхние

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

2

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

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

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


4
Мне надоел аргумент «X - это хорошо, Y принуждает к связанной вещи Z, поэтому Y делает добро, применяя X» (например, нормальный стиль кодирования / Python / правило офсайда). Ни один хороший программист не извлекает выгоду таким образом, что это серьезно влияет на читабельность, даже если это разрешено. Те, кто злоупотребляет нечувствительностью к регистру, также непоследовательно извлекают выгоду из чувствительной к регистру среды (и совершают сотню других злодеяний), они просто вынуждены использовать одну и ту же плохую заглавную букву для каждого использования отдельного имени. Плохие программисты могут писать на Фортране на любом языке. (Отказ от ответственности: я большой поклонник чувствительности к регистру!)

Угадай, что. Мне надоело читать код, написанный плохими программистами, которые считают себя такими хорошими программистами, что могут разрабатывать свои собственные уникальные правила стиля. (Отказ от ответственности: я научился программировать во времена Фортрана и Кобола, и я ненавижу нечувствительность к регистру и другие лингвистические зверства той эпохи.)
Стивен С.

Любое использование заглавных букв в нечувствительном к регистру языке означает злоупотребление нечувствительностью.
Каз

@ Kaz - эм ... попробуйте рассказать об этом миллионам программистов SQL.
Стивен К

1

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

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

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

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

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


Чувствительность к регистру не ставит компьютер перед удобством пользователя. Я реализовал регистрозависимые и нечувствительные к регистру языки, и единственное отличие заключается в дополнительном вызове функции в нескольких местах. Кроме того , другие ответы говорят , что дело в -sensitivity исторический артефакт из - за ограниченного набора символов - противоречит вашей теории, не так ли?

Юникод помещает это в совершенно другое царство.
DeadMG

3
Этот блог не дает никаких объяснений, почему он плох в C, только в Python или PHP - и OP не говорит об идентификаторах, чувствительных к регистру, только о ключевых словах . Эта ссылка не имеет ничего общего по этому вопросу.
DeadMG

1
Редакторы @Ben могут (и делают) исправлять регистр при вводе независимо от правил языка. Разрешение ошибок, которые тем не менее проскальзывают (например, потому что у вас нет необычного редактора под рукой), не помогает. Это означает оставить проблему вокруг, вместо того, чтобы жаловаться на нее, чтобы решить ее. Более того, как только я использую согласованную заглавную букву, у меня может быть несколько идентификаторов, различающихся регистром, но обозначающих очень разные вещи и легко разбираемых для людей благодаря контексту и капитализации, без двусмысленности.

2
@Ben: В некоторых языках существуют очень строгие лексографические обычаи или даже правила. В C и C ++ all-caps является макросом, и макросы должны оставаться all-caps, чтобы избежать путаницы. Некоторые языки имеют разные значения для символов с или без начальных заглавных букв (и я не знаю, насколько хорошо они будут работать на разных языках, которые не имеют соответствующих прописных и строчных букв). Если у вас есть подобные правила или соглашения, вы получаете эффект от разных пространств имен, и дублирование имен идентификаторов в разных пространствах имен часто работает.
Дэвид Торнли

1

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

Более важным является именование и структурные соглашения, которые программист должен хранить в своем коде, и никакой компилятор или парсер не проверяет его за него. Если вы придерживаетесь каких-то правил, вы легко узнаете правильное имя (вы не будете думать, назвали ли вы переменную 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, который может привести к кошмарному коду даже когда есть чувствительность к регистру, так что это не большая разница).


1

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

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

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

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

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

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


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

Я не возражаю HWND hwnd;. Это пример, где чувствительность к регистру работает хорошо. Соглашение "Индийского холма" всех заглавных букв глупо, хотя. hwnd_t hwndнамного лучше. Я подозреваю, что это все из-за FILE. Когда - Version 6 Unix имел в своем файле ввода / вывода заголовка библиотеки этого: #define FILE struct _iobuf. Это было во всех заглавных буквах, потому что это был макрос. Когда он стал typedef в ANSI C, орфография всех заглавных букв была сохранена. И я думаю, что именно подражанием этому было изобретено соглашение ALL_CAPS_TYPE, которое кодифицировано в Руководстве по стилю Индийской горки Bell Lab. (Оригинальное!)
Kaz

Если вы сейчас ищете «Руководство по стилю Indian Hill», вы найдете в основном ссылки на документ 1990 года от Bell Labs, в котором полностью раскаиваются все названия заглавных букв typedef: никаких следов такой рекомендации нет. Но в оригинальной версии рекомендуются такие вещи, как typedef struct node *NODE. Я уверен, что именно здесь Microsoft должна была понять это. Так что вините в этом Bell Labs HWND.
Каз

1

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

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

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

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

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

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

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

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

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

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

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


1
Хорошо, так companyName == companyname. Это кажется разумным, но как вы справляетесь с локалями? Будет ли компиляция вашей программы в разных частях света вызывать различную семантику, как это происходит в PHP? Будете ли вы полностью англоцентричны и будете поддерживать только ASCII-набор для печати в идентификаторах? Нечувствительность к регистру - это большая сложность для очень небольшого дополнительного выигрыша.
Фоши

0

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

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


1
Сравнение случаев не так сложно. Просто разложите ваши идентификаторы. Е = Е '= е' = é. Помните, что вы можете выбрать , который случай правила следовать, и английский является разумным выбором. (конечно, если ваши ключевые слова тоже английские)
MSalters

2
Да, они «такие трудные» во всем пространстве Юникода.
Каз

1
«Программисты в эту эпоху ожидают чувствительности к регистру»? Только если у них Стокгольмский синдром от слишком долгой работы с семьей С.
Мейсон Уилер

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

0

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

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

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

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

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

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

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

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

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

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

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


1
Я думаю, что вы хотели сказать "нечувствительность к регистру - это кошмар". У японцев есть случай: хирагана и катакана - это разные случаи. Точно так же, как А и А в определенном смысле «одинаковы», так и あ и ア. Катакана иногда используется для акцента, аналогично верхнему регистру в языках, где используется римский алфавит. Само собой разумеется, было бы идиотизмом рассматривать хирагану и катакану в идентификаторах языка программирования как одно и то же.
Каз

Спасибо - это обогащает! Я немного почистил свой пост.
ГленПетерсон

1
Car car;Это один из лучших аргументов против чувствительности к регистру: это ужасно, и если ваш язык нечувствителен к регистру, вы не можете злоупотреблять чувствительностью к регистру таким образом.
Мейсон Уилер

1
Является Car myCar; так много лучше?
ГленПетерсон

@ Мейсон Уилер: Если мы ограничим наши языковые конструкции теми, кого мы не можем злоупотреблять, мы не сможем многое сделать, не так ли? Мой совет любому, кто злоупотребляет чувствительностью к регистру: «Не надо».
Дэвид Торнли
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.