Чому в деяких мовах програмування все ще існує чутливість регістру?

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

Навіщо реалізовувати це мовою програмування?

Оновлення:

Схоже, хтось, кого ви знаєте, зробив заяву з цього приводу .

Хоча складання корпусів в англійській мові досить тривіально, в інших інших мовах це набагато менше. Якщо німецький програміст використовує ßім’я змінної, що ви збираєтесь вважати великим регістром? Просто FYI, "ß" використовується лише в нижньому регістрі. Ото, «сс» є еквівалентом - Ви б компілятор зобов'язаний зіставити їх? Коли ви потрапляєте в Unicode, у вас виникають ще цікавіші проблеми, наприклад, символи з попередньо складеними діакритичними позначками порівняно з окремими поєднаннями діакритики. Тоді ви перейдете до деяких арабських сценаріїв, з трьома окремими формами багатьох букв, а не лише двома.

У похмурі століття більшість мов програмування були нечутливими до випадків, коли вони майже не потрібні. Наприклад, Паскаль запустився в мейнфрейми Control Data, які використовували лише шість біт на символ (всього 64 коди). Більшість таких машин використовували набір символів "CDC Scientific", який містив лише великі літери. Ви можете переключитися на інші набори символів, але більшість мали великі або малі регістри, але не обидва - але використовували однакові коди для обох. Те саме стосувалося стародавніх кодів Бодо і таких, які вважалися стандартними в перші дні COBOL, FORTRAN, BASIC тощо. До того часу, коли більш доступне обладнання було широко доступне, їх чутливість до справ була настільки ретельно вбудована, що змінити його було неможливо .

З часом реальна складність нечутливості до випадків стала більш очевидною, і мовні дизайнери здебільшого вирішили ("зрозуміли", мабуть, більш точний термін), що коли / якщо люди дійсно хочуть нечутливості до справи, то краще обробляти допоміжні інструменти ніж у самій мові.

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

Чому хтось хотів би нечутливості? У якому сценарії корисно мати можливість посилатися на одну змінну як VARIABLEв одному місці, Variableв іншому, так і variableв третьому? Справа нечутливість викликає роздратування. Я набагато скоріше отримаю помилку компілятора, коли я випадково наберіть VAriableзамість цього, Variableа не дозволю, щоб випадкові помилки, як це, проскочили в мій код.

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

У Java випадку чутливість НЕ використовується для надання більшої кількості варіантів коду, а для дуже чіткого та послідовного смислового значення. ЗаняттяLookLikeЦе. objectLookLikeЦе. methodLookLikeThis (). STATIC_VARIABLES_LOOK_LIKE_THIS. Classes.WithInnerClassesLookLikeThis. Він НЕ забезпечує більшої свободи: дозволяє збивати якусь інформацію вкрай, що є інакше надмірно багатослівною мовою.

Я думаю, що в явно статичних типах мов із компілятором mucho та підтримкою IDE чутливість до регістру - це чудовий спосіб передачі інформації (наприклад, Java). У таких мовах, як Ruby, нечутливість регістру, ймовірно, спричинить навіть БІЛЬШЕ несподівані результати, хоча я б був відкритий для того, щоб спробувати Ruby, нечутливий до регістру.

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

      joe blah = new hUf();

це досить зрозуміло, але як бути:

      hUf.WTF();

У Java як такої є, ви б автоматично знали, що це. У Java-нечутливій Java це неоднозначно, тож вам доведеться вдатися до якогось іншого механізму для диференціації класів від екземплярів від пакетів від методів. І цей механізм, ймовірно, змусить вас блювотити, як це некрасиво :)

Я не думаю, що це було "реалізовано" настільки, наскільки "дозволено". Чутливість регістру - це стан порівняння рядків за замовчуванням; для інженера-компілятора потрібна додаткова робота, щоб зробити мовний регістр нечутливим, оскільки вам потрібно додати додатковий код для порівняння нечутливих до регістру та збереження оригінальних імен токенів для правильного повідомлення про помилки та попередження.

Це майже напевно, чому він опинився в C; вони хотіли скласти просту мову, для якої компілятор було легко реалізувати, за рахунок зручності використання. Що стосується того, чому це в сучасних мовах? Тому що це в C, звичайно, тому це повинен бути правильний шлях! </ sarcasm mode>

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

У випадку нечутливого до регістру розбору вам обмежуватиметься використання унікальних ідентифікаторів, оскільки "myClass" та "MyClass" були б одним і тим же. Крім того, вам доведеться додати шари складності до свого аналізатора, щоб переконатися, що ви могли визначити, який ідентифікатор використовується на основі контексту.

Розглянемо такий випадок:

XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");

Припустимо, клас XmlWriter також має статичний метод, який називається "Write". Ви називаєте це на екземплярі чи на класі, якщо тут не застосовується чутливість до регістру?

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

this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename

Я, як правило, програмую в Python, але ще в моїх C # днях мені здалося, що дуже зручно називати екземпляри класу такими ж, як і клас, але нижній (або верблюд) регістр (як уже говорили інші):

Thing thing = new Thing();

Використання нечутливих до регістру мов вимагає певної конвенції для цього, тобто, певного типу сигілів, таких як:

Thing oThing = new Thing()
Thing instanceOfThing = new Thing()

Що "погана річ".

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

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

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

Візьміть мову як приклад. Чому ми починаємо речення і називаємо речі великими літерами ... Це також через unix?

Я думаю, що для статично набраних ланагуаз, таких як C # та Java, це насправді не додає ніякої цінності. Оскільки в більшості випадків у вас є IDE, який все одно автоматично виправить невідповідність справи, тож наприкінці дня, якщо я випадково надам "VAriable", мій IDE автоматично виправить це на " Змінна "для мене. Додайте до цього MyClass myClass;конвенції стилів, і ви можете побачити, що чутливість до регістру не обов'язково є поганою справою.

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

Отже, так, хоча мови, що не існує справжньої причини, не могли б бути чутливими до регістру, але також немає реальної причини, чому вони повинні бути будь-якими.

Ця стаття Скотта Хензельмана про "SignOn" проти "Signon" стосувалася порівняння рядків і нічого спільного з мовами програмування. Я погоджуюся, що рядки, які вводять користувачі, завжди повинні порівнювати регістри без чутливості, але я думаю, що це інша куля гри з ідентифікаторами мови програмування.

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

• У теорії ймовірностей нижній регістр fзазвичай представляє функцію щільності ймовірності (pdf), тоді як верхній регістр Fявляє собою відповідну функцію кумулятивного розподілу (cdf).
• Також в теорії ймовірностей великі літери позначають випадкові величини X, а відповідні малі літери позначають їх реалізацію x, як у $ Pr [X = x] \ leq 0,05 $.
• У лінійній алгебрі великі літери зазвичай використовуються для позначення матриць, тоді як малі літери зазвичай використовуються для позначення чисел, наприклад, $ A = [a_ {ij}] $.
• Символи одиниць записуються малими літерами (наприклад, m за метр), за винятком літра (L) і тих одиниць, що походять від імені людини (W для Вт, Па для Паскаля, N для Ньютона тощо).
• Символи префіксів, що означають мільйон або більше, мають великі літери (М для мега (мільйони)), а ті, які менші за мільйон, мають малі регістри (м на мілі (тисячні)).

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

Я використовую обґрунтування того, що Кури у "Пасхальному зайчику приїжджають у місто", коли їх запитували, чи прийшли вони перед яйцем. Оскільки на Ноєвому ковчезі були кури, першими з’явилися кури. Тому, оскільки GCC працює на Unix, Unix вийшов першим, тому, оскільки Unix так сильно піклується про case, C та всі його варіанти та нащадки, так що все, що накладає фігурні дужки, піклується про case.

Напевно, існує зв’язок між фігурними брекетами та чутливістю корпусу.

На додаток до відмінних відповідей, що даються до цього часу, я хочу зазначити, що чутливість регістру дає вам також додаткові "простори імен". Наприклад, Perl має декілька спеціальних блоків, таких як BEGINі ENDякі працюють у різний час, ніж звичайний код (BEGIN під час компіляції, END після закінчення нормальної програми), а наявність таких як all-caps вилучає їх, і це означає, що нижній регістр варіанти - це не зарезервовані слова.

Можна піти ще далі і зарезервувати всі великі імена для подальшого використання мовою, і не заподіюйте шкоди нормальним програмістам, які зазвичай НЕ ПОТРІБНУЮТЬСЯ У КОДІ.

"Технічні особи" завжди краще, щоб технічні особи зменшили неоднозначність. Візьмемо назву файлу як приклад. Робота з іменем файлу Windows викликає більше проблем, ніж ім'я файлу Unix, оскільки ім'я файлу в Windows нечутливе до регістру, а ім'я файлу в Unix залежить від регістру.

Повернення до програмування. Для імені класу, імені методу, імені змінної, більшість мов не застосовують правило стилю іменування. Іноді для простоти "відображення" ми можемо просто використовувати ім'я "Чутливий до регістру", щоб прив'язати до іншого джерела даних без перетворення, або обробляючи проблему з однойменною назвою, але в іншому випадку.

Я здивований цією розпускою. Тепер, коли ніхто не хоче, щоб ви використовували підкреслення або m_ім’я поля в C #, я щойно використовував випадок верблюда, і якщо назва поля збігається з назвою загальнодоступної власності, просто те, що назва публічної власності - це випадок Pascal а поле підкладки - це корпус верблюда, я вважаю, "так і буде" - саме цього, схоже, хоче спільнота програмування. Поки що це не викликало жодних проблем.

Особливо деякі програмісти походять з перших днів BASIC, де ім'я змінної може бути довжиною лише 2 символи.

І так, коли це може бути будь-яка кількість персонажів, вони стають дуже щасливими. І разом із чутливістю до регістру - адже вони не хочуть також дбати про SomeNameте, щоб випадково дорівнювати SOMENAMEта викликати помилку через подібні речі.