Нечутливі до регістру ключові слова мовою [закрито]

Ми намагаємось написати власну мову сценаріїв. Було запропоновано зробити мову прощальною, надавши нечутливі до регістру ключові слова.

Мені особисто не подобається ідея, але в моїй команді мало хто схиляється до неї, кажучи, що це зробить кінцевого користувача щасливим! Наведені приклади таких мов, як 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 line може відображати нижній регістр на верхній на виході, а він може відображати верхній регістр на нижній регістр на нижньому. Це дозволяє працювати мовою програмування малої літери, на терміналі, що не має нижнього регістру.

Нечутливість до випадків - це застаріла концепція минулої епохи комп'ютера, яка не дуже добре працює в сучасному світі інтернаціоналізованих обчислень. Ви поширюєте це на інші мови? Як щодо французької: чи вважаєте ви equivalent і è рівнозначними? Або японці? Чи вважаєте ви хірагану та катакана просто випадками, так що フ ァ イ ル і ふ ぁ い る є однаковим ідентифікатором? Підтримка такої дурості значно ускладнить ваш лексичний аналізатор, який повинен мати карти еквівалентності випадків для всього простору Unicode.

Зауважте, що математика відрізняється від регістру. Наприклад, сигма верхнього регістру може позначати підсумовування, тоді як сигма в нижньому регістрі позначає щось інше, наприклад стандартне відхилення. Це може відбуватися в одній формулі, не створюючи труднощів. (Чи будуть мови програмування еквівалентними Σ і σ?)

Англійська орфографія чутлива. Наприклад, багатьом власним іменникам відповідають звичайні іменники або навіть інші частини мови. "може" - дієслово, але "травень" - місяць, або ім'я жінки. Більше того, якщо абревіатура або абревіатура пишеться в малому регістрі, це може бути заплутано. SAT означає тест на схоластичну працездатність, тоді як "sat" є минулим дієприкметником "sit". Розумні люди звертають увагу на деталі та правильно використовують їх.

В основному, будь-яка нова мова програмування, створена з 1985 року, що не відрізняється від регістру, - це для тих, хто все-таки просунеться в електронній пошті та розміщеннях без другої думки.

Що робити, якщо ваша мова коли-небудь використовується як цільове створення коду для перекладу коду на іншу мову, а інша мова має чутливі регістри? Вам доведеться якось перетворити всі імена, щоб захопити відмінність. (Отже, стверджувати, що це не технічне рішення, а лише питання емоційних уподобань цільової аудиторії, є смішним.)

Подивіться на набридливі проблеми, спричинені обробкою справ у Windows, коли файли імпортуються з іншої операційної системи. Це технічне питання. Файлові системи, що враховують регістри, мають проблеми з іноземними даними, які не чутливі до регістру.

Звичайний Лісп вдався до ідеального підходу: назви символів залежать від регістру, але коли лексеми читаються, вони складаються у верхній регістр. Це означає , що маркери foo, fOO, FOOі Fooвсе позначають той же символ: символ, ім'я якого зберігається в вигляді рядка символів "FOO". Крім того, така поведінка є лише конфігурацією таблиці зчитування за замовчуванням. Читач може скласти літери до великого регістру, до нижнього регістру, перевернути регістр або зберегти його. Останні два варіанти викликають чутливий до регістру діалект. Таким чином, користувачі мають максимальну гнучкість.

Справжнім визначальним фактором є те, як часто ви хочете мати кілька речей з одним іменем. Case нечутливість працює в 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: Якщо у вас є вибір між поганим рішенням, яке легко здійснити, і хорошим рішенням, яке важче реалізувати, виберіть неправильне рішення і відсуньте тягар роботи навколо вашого безладу на користувач. Це може здатися химерним, але це абсолютно правда. Він відомий як принцип "гірше - це краще", і він несе пряму відповідальність за збитки в мільярди доларів протягом останніх кількох десятиліть через C і C ++, що робить його занадто простим у написанні гнучкого і небезпечного програмного забезпечення.

Зробити мовну справу нечутливою, безумовно, простіше; вам не потрібні таблиці лексерів, аналізаторів та символів, щоб виконувати додаткову роботу, щоб забезпечити, щоб все відповідало випадку, нечутливому до випадку. Але це також погана ідея з двох причин:

• По-перше, особливо якщо ви будуєте мову сценаріїв, простий друкарський помилок, коли ви називаєте щось "myObject" в одному місці та "MyObject" в іншому, де ви, очевидно, посилаєтесь на один і той же об'єкт, але просто трохи не узгоджуєтеся з великої літери , не перетворюється на помилку виконання. (Це сумнозвісно як головний біль у мовах сценаріїв, які помиляються, наприклад, Python.)
• По-друге, відсутність чутливості до регістру означає, що чутливість регістру не може бути зловживана тим, що одне і те ж слово посилається на дві різні речі в тій самій області лише шляхом зміни великої літери. Якщо вам коли-небудь доводилося працювати з кодом Windows у середовищі C, і наштовхуєтесь на некрасиві декларації, як-от HWND hwnd;, ви точно знатимете, про що я говорю. Людей, які пишуть так, слід виводити та знімати, а мовна справа нечутлива запобігає зловживанню чутливістю випадків потрапляти у ваш код.

Тому докладіть додаткових зусиль, щоб це правильно. Отриманий код буде більш чистим, легшим для читання, меншою помилкою та зробить ваших користувачів більш продуктивними, і чи не це кінцева мета будь-якої мови програмування?

Я не можу повірити, що хтось сказав, що "чутливість регістру полегшує читання коду".

Це, звичайно, ні! Я переглянув плече колеги на змінні під назвою Компанія та компанія (публічна змінна компанія, відповідна приватна змінна компанія), і його вибір шрифту та кольору робить неймовірно складно визначити різницю між цими двома - навіть коли знаходяться поруч.

Правильне твердження повинно бути "змішаний регістр полегшує читання коду". Це набагато очевидна істина - наприклад, змінні під назвою CompanyName та CompanyAddress, а не назва компанії. Але жодна мова, про яку я знаю, не змушує вас використовувати лише малі імена змінних змінних.

Найбільш божевільна умова, про яку я знаю, - це "велика загальна, нижня літера". Це просто прохання про неприємності!

Я вважаю, що помилки - «краще, щоб щось не вдалося шумно і якомога швидше, а не тихо вийти з ладу, але, схоже, вдалося». І немає часу, ніж час складання.

Якщо ви помилково використовуєте нижню величину великого регістру, коли ви мали намір використовувати верхній регістр, вона часто компілюється, якщо ви посилаєтесь на неї в одному класі . Таким чином, ви можете досягти успіху і в компіляції, і в запуску, але тонко робите неправильну справу і, можливо, не виявляєте її тривалий час. Коли ви виявите, що щось не так

Набагато краще використовувати конвенцію, де приватна змінна має суфікс - наприклад, загальнодоступна змінна компанія, приватна змінна CompanyP. Ніхто не збирається випадково переплутати їх, і вони з'являються разом у інтелігенції.

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

Ця конвенція має всі переваги жахливої ​​конвенції верхнього та нижнього регістру та жодних її недоліків.

Те, що люди відчувають необхідність апелювати до чутливості до випадків, щоб розрізняти змінні, свідчить як про брак уяви, так і на відсутність здорового глузду. Або, на жаль, людські вівці люблять звик дотримуватися конвенції, оскільки "так завжди робилося"

Зробіть речі, з якими ви працюєте, чітко і очевидно відрізняються один від одного, навіть якщо вони пов'язані !!

Не слід вводити нечутливість до справи без дуже вагомих причин для цього. Наприклад, займатися зіставленням випадків з Unicode може бути сукою. Чутливість регістру (або його відсутність) для старих мов несуттєва, оскільки їх потреби були дуже різними.

Програмісти в цю епоху очікують чутливості до справ.

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

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

• Це дозволяє / заохочує CamelCase таким чином, що одне й те саме слово з різним регістром може посилатися на споріднені речі: Car car; Таким чином, назва змінної carстворюється типу Car.

• ALL_CAPS_WITH_UNDERSCORES вказує константи за умовами багатьох мов

• all_lower_with_underscores можна використовувати для змінних членів або чогось іншого.

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

• Якщо мова буде інтерпретована, можливо, буде застосовано покарання за невиконання синтаксичного розбору коду.

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

Яка користь? 3 мови, які ви згадуєте, - починаючи з 1970-х чи раніше. Жодна сучасна мова цього не робить.

З іншого боку, все, що насправді робить кінцевого користувача щасливим, приносить трохи світла у світ. Якщо це дійсно вплине на щастя користувача, то вам доведеться це зробити.

Якщо ви хочете зробити це по-справжньому простим для кінцевих користувачів, ви можете зробити краще, ніж чутливість / нечутливість випадку - погляньте на Scratch ! Кілька менших мультфільмів і більше сприятливих для бізнесу кольорів, і ви маєте про найдружнішу мову, яку я коли-небудь бачив - і вам нічого не потрібно писати! Просто думка.