Чи однозначні константи кращі за буквальні?

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

Основне заклик використання констант полягає в тому, що вони мінімізують обслуговування, коли потрібні зміни. Але коли ми почнемо використовувати символ, інший ніж ',' для позначення коми?

Єдина причина, яку я бачу для використання констант замість літералів, - це зробити код більш читабельним. Але чи city + CharacterClass.COMMA + state(наприклад) насправді читабельніше, ніж city + ',' + state?

Для мене мінуси переважують плюси, головним чином, що ви вводите інший клас та інший імпорт. І я вірю в менше коду, де це можливо. Тож мені цікаво, який тут загальний консенсус.

Тавтологія :

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

Здоровий глузд говорить вам про те, що const char UPPER_CASE_A = 'A';або const char A = 'A'не додає нічого, крім обслуговування та складності вашій системі. const char STATUS_CODE.ARRIVED = 'A'інший випадок.

Константи повинні представляти речі, незмінні під час виконання, але, можливо, їх потрібно буде в майбутньому змінити під час компіляції. Коли const char A =правильно рівне нічого, крім A?

Якщо ви бачите public static final char COLON = ':'код Java, знайдіть того, хто написав це, і зламайте їхні клавіатури. Якщо представництво на вас COLONколись зміниться, у :вас виникне кошмар на підтримку.

Опуднення:

Що станеться, коли хтось змінить його, COLON = '-'тому що там, де вони його використовують, потрібно -натомість скрізь? Чи збираєтесь ви писати одиничні тести, які в основному кажуть assertThat(':' == COLON)для кожної constпосилання, щоб переконатися, що вони не змінюються? Тільки, щоб хтось виправив тест, коли вони їх змінили?

Якщо хтось насправді стверджує, що public static final String EMPTY_STRING = "";це корисно і корисно, ви просто кваліфікували їх знання та сміливо ігноруєте їх у всьому іншому.

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

Згуртованість:

Це також штучно знижує згуртованість, оскільки відсуває речі від речей, які ними користуються, і пов'язані з ними.

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

З'єднання:

Він також поєднує безліч непов'язаних класів разом, оскільки всі вони в кінцевому підсумку посилаються на файли, які насправді не пов'язані з тим, що вони роблять.

Щільне з'єднання - це коли заняття групи сильно залежать один від одного. Цей сценарій виникає тоді, коли клас бере на себе занадто багато обов'язків або коли одна турбота поширюється на багато класів, а не на власний клас.

Якби ви використовували краще ім’я, як у DELIMITER = ','вас, все-таки виникли б ті самі проблеми, тому що ім'я є загальним і не має семантичного значення. Переназначення значення більше не допомагає зробити аналіз впливу, ніж пошук та заміна буквального ','. Тому що, який код використовується, він потребує, ,а якийсь інший код використовує, але потребує ;зараз? Ще потрібно дивитися на кожне використання вручну та змінювати їх.

В дикій природі:

Нещодавно я відновив 1,000,000+ LOCпрограму, якій було 18 років. Були такі речі public static final COMMA = SPACE + "," + SPACE;. Це жодним чином не краще, ніж просто викласти " , "там, де це потрібно.

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

Він також ,визначав кілька разів з декількома неправильними написаннями слова COMMAв декількох пакунках і класах. З посиланнями на всі варіанти, змішані разом у коді. Нічого кошмару не було, ніж спробувати щось виправити, не порушуючи щось абсолютно не пов’язане між собою.

Те ж саме з алфавітом, було кілька UPPER_CASE_A, A, UPPER_A, A_UPPERщо більшу частину часу були рівні , A але в деяких випадках не було . Майже для кожного персонажа, але не для всіх персонажів.

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

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

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

Основне заклик використання констант полягає в тому, що вони мінімізують обслуговування, коли потрібні зміни.

АБСОЛЮТНО НІ. Це зовсім не причина використання констант, оскільки константи не змінюються за визначенням . Якщо константа колись змінюється, то це не була константа, чи не так?

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

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

Хитрість тут полягає не в ухиленні від констант, а в тому, щоб назвати їх своїми семантичними властивостями, а не їх синтаксичними властивостями . Для чого використовується константа? Не називайте це, Commaякщо бізнес-домен вашої програми - це типографія, розбір англійської мови тощо. Назвіть це ListSeparatorчи щось подібне, щоб зрозуміти семантику речі.

Ні, це німе.

Що НЕ обов'язково німий витягати такі речі , як , що в названі етикетки з причин локалізації. Наприклад, роздільник тисячі - це кома в Америці (1 000 000), але не кома в інших регіонах. Потягнувши це на названий ярлик (з відповідним ім'ям без коми), програміст може ігнорувати / абстрагувати ці деталі.

Але робити постійною, тому що "магічні струни погані" - це просто вантаж.

Є кілька символів, які можуть бути неоднозначними або використовуватися для декількох різних цілей. Наприклад, ми використовуємо '-'дефіс, знак мінус або навіть тире. Ви можете зробити окремі імена як:

static const wchar_t HYPHEN = '-';
static const wchar_t MINUS = '-';
static const wchar_t EM_DASH = '-';

Пізніше ви можете змінити код, щоб він не розмежувався, перезначивши їх як:

static const wchar_t HYPHEN = '-';
static const wchar_t MINUS = '\u2122';
static const wchar_t EM_DASH = '\u2014';

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

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

Постійна повинна додавати значення.

Визначення COMMA як кома не додає значення, оскільки ми знаємо, що кома є комою. Натомість ми руйнуємо сенс, тому що зараз COMMA фактично вже не може бути комою.

Якщо ви використовуєте кому для певної мети і хочете використовувати названу константу, назвіть її після її призначення. Приклад:

• city + CharacterClass.COMMA + state = погано
• city + CITY_STATE_DELIMITER + state = хороший

Використовуйте функції для форматування

Мені особисто більше подобається FormatCityState(city, state)і мені все одно, як виглядає тіло цієї функції, поки воно коротке і проходить тестові випадки.

Ідея про те, що постійний COMMA кращий ','або ","досить легкий для розвінчання. Звичайно, є випадки, коли це має сенс, наприклад, final String QUOTE = "\"";значно економлять на читанні без усіх косих рис, але символи, що контролюють мову заборони, як, \ 'і "я не вважаю їх дуже корисними.

Використання final String COMMA = ","- це не тільки погана форма, це небезпечно! Коли хтось хоче змінити роздільник ","на, ";"він може піти змінити файл констант, COMMA = ";"оскільки це швидше це зробити, і він просто працює. Крім того, ви знаєте, всі інші речі, які використовували COMMA зараз, також є крапками з комою, включаючи речі, надіслані зовнішнім споживачам. Таким чином, він проходить усі ваші тести (тому що весь код маршалування та демарширування також використовував COMMA), але зовнішні тести не зможуть.

Що корисно - це дати їм корисні імена. І так, іноді кілька констант матимуть однаковий вміст, але різні назви. Наприклад final String LIST_SEPARATOR = ",".

Таким чином, ваше запитання: "чи є єдині константи char краще, ніж букви", і відповідь нерівнозначно "ні", вони ні. Але навіть краще, ніж обидва ці, це вузькообласне ім'я змінної, яке прямо говорить, яка її мета. Звичайно, ви витратите кілька додаткових байт на ці додаткові довідки (якщо припустимо, що вони не будуть складені на вас, що, напевно, буде), але в довгостроковому обслуговуванні, саме там більша частина вартості програми, вони варті того часу, щоб зробити.

Я робив деякі роботи, писав лексеми та парсери і використовував цілі константи для представлення терміналів. Одно символьні термінали, як правило, мали код ASCII як їх числове значення для простоти, але код міг бути зовсім іншим. Отже, я мав би T_COMMA, якому було призначено ASCII-код для ',' як його постійне значення. Однак існували також константи нетерміналів, яким було призначено цілі числа вище набору ASCII. Подивившись на генератори парсера, такі як yacc чи зубр, або парсери, написані за допомогою цих інструментів, у мене склалося враження, що це в основному, як всі це робили.

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

Я можу придумати ще кілька поодиноких випадків, коли могло б мати сенс використовувати константи замість відповідних літералів. Наприклад, ви можете вказати, що NEWLINE є буквальним '\ n' у вікні Unix, але '\ r \ n' або '\ n \ r', якщо ви знаходитесь у вікні Windows або Mac. Те саме стосується розбору файлів, які представляють табличні дані; Ви можете визначити константи FIELDSEPARATOR та RECORDSEPARATOR. У цих випадках ви фактично визначаєте константу для представлення символу, який виконує певну функцію. Тим не менш, якби ти був початківцем програмістом, можливо, ти назвав би свій роздільник поля постійним COMMA, не розуміючи, що ти повинен був би назвати його FIELDSEPARATOR, і до того часу, як ти зрозумів, код буде вироблятися, і ти будеш наступним проект,

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

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

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

Хороші абстракції роблять код простим у використанні, з одного боку, та легким у підтримці, з іншого.

Я повністю погоджуюсь, що саме DELIMITER=':'по собі є поганою абстракцією, і лише кращою, ніж COLON=':'(оскільки остання збідніла).

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

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

Основне заклик використання констант полягає в тому, що вони мінімізують обслуговування, коли потрібні зміни.

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

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

В обох випадках використання названого символу подібне COMMAдопомагає забезпечити згуртованість інакше нерозбірного продукту. Ця величина часто може перевищувати вартість надмірно багатослівних позначень.

Зауважте, що ви намагаєтесь скласти список.

Отже, переробляйте це як: String makeList(String[] items)

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

Якщо це був клас, написаний як частина заявки вашого колеги-розробника, це майже напевно погана ідея. Як вже вказували інші, має сенс визначати константи, наприклад, SEPARATOR = ','де можна змінити значення, а константа все ще має сенс, але набагато менше, ніж константи, назва яких описує лише їх значення.

Однак є щонайменше два випадки, коли має сенс оголошувати константи, ім'я яких точно описує їх зміст, і де ви не можете змінити значення без належної зміни назви константи:

• Математичні чи фізичні константи, наприклад PI = 3.14159. Тут роль константи полягає в тому, щоб діяти як мнемонічне, оскільки символічне ім'я PIнабагато коротше і читабельніше, ніж значення, яке воно представляє.
• Вичерпні списки символів в аналізаторі або клавішах на клавіатурі. Можливо, навіть є сенс скласти список констант з більшістю або всіма символами Unicode, і саме тут може потрапити ваш випадок. Деякі символи, такі як Aочевидні та чітко впізнавані. Але чи можна легко розказати Аі Aрозставити? Перший кирилична буква А , а остання латинська буква А . Це різні букви, представлені різними кодовими точками Unicode, хоча графічно вони майже однакові. Я вважаю за краще константи CYRILLIC_CAPITAL_AіLATIN_CAPITAL_Aв моєму коді, ніж два майже однакових на вигляд символи. Звичайно, це безглуздо, якщо ви знаєте, що будете працювати лише з символами ASCII, які не містять кирилиці. Так само: я використовую латинський алфавіт щодня, тому якби писав програму, яка потребувала китайського символу, я, мабуть, вважаю за краще використовувати константу, а не вставляти символи, які я не розумію. Для тих, хто щодня використовує китайські символи, китайський символ може бути очевидним, але латинський може бути легше представити як названу константу. Отже, як бачите, це залежить від контексту. Тим не менш, бібліотека може містити символічні константи для всіх символів, оскільки автори не можуть заздалегідь знати, як бібліотека буде використовуватися та яким символам можуть знадобитися константи для поліпшення читабельності в певній програмі.

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

Може бути.

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

city + '.' + state

тоді як це порівняно важка помилка

city + Const.PERIOD + state

Залежно від вашого інтернаціоналізації та глобалізації, різниця між апострофом ASCII та відкритим і закритим апострофом Windows-1252 (або подвійною цитатою ASCII та подвійною цитатою Windows-1252, відкритою та закритою подвійною цитатою) може бути суттєвою і, як відомо, важко візуалізувати погляд за кодом.

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

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

Чи однозначні константи кращі за буквальні?

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

Константи забезпечують:

• семантика
• зміни, під час розвитку
• непрямість

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

Буквальне і константне може змінюватися і під час розвитку. Це те, що викликає питання про магічне число. Струни можуть бути і магічними числами.

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

Непрямий спосіб може вирішити будь-яку проблему, крім сильної непрямості.

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

Непрямістю можна переборщити. Деякі вважають за краще шукати та замінювати літерали для внесення змін. Це добре, якщо 42 явно є сенсом життя, а не змішується разом з 42, атомним числом молібдену.

Де ви можете зробити такі корисні відмінності, як одна буква, багато в чому залежить від контексту. Але я б не зробив це звичкою.

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

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

Г. К. Честертон, М'яч і Хрест

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

Якщо ти брешеш за комп’ютером, він отримає тебе

Перрі Фаррар - Германтаун, штат Меріленд (від More Pearls of Programming)

Але здебільшого я згоден з людьми, які кажуть, що це німо. Я занадто молодий, щоб навчитися програмувати FORTRAN, але чув, як можна сказати, що ви можете переосмислитись 'A' = 'Q'і придумати всілякі чудові криптограми. Ви цього не робите.

Поруч із проблемами i18n, які виникали раніше (які не переосмислюють гліф "COMMA", а справді переосмислюють гліф DECIMAL_POINT). Побудова французьких морквяних цитат або британських одинарних цитат для того, щоб передати зміст людині, є справді, і вони дійсно повинні бути змінними, а не константами. Постійна була б AMERICAN_COMMA := ','іcomma := AMERICAN_COMMA

І, якби я використовував шаблон побудови для побудови SQL-запиту, я б швидше побачив

sb.append("insert into ")
 .append(table_name)
 .append(" values ")
 .append(" ( ")
 .append(val_1)
 .append(",")
 .append(val_2)
 .append(" ); ")

ніж будь-яка інша річ, але якби ви збиралися додавати константи, це було б

INSERT_VALUES_START = " ( "
INSERT_VALUES_END = " ) "
INSERT_VALUES_SEPARATOR = " , "
QUERY_TERMINATOR = ";"

sb.append("insert into ")
 .append(table_name)
 .append(" values ")
 .append(INSERT_VALUES_START)
 .append(val_1)
 .append(INSERT_VALUES_SEPARATOR)
 .append(val_2)
 .append(INSERT_VALUES_END)
 .append(QUERY_TERMINATOR)

Однак якщо ви коли-небудь дивилися, щоб хтось інший програмував (або вводив), ви можете помітити цікаві химерності. Не всі ми зоряні машиністки. Багато хто з нас запізнювались на програмування або піднімалися за допомогою радянських клавіатур (де клавіші вводяться на вас), і ми любимо вирізати та вставляти окремі літери, а не намагатися знайти їх на клавіатурі та / або покладатися на автозаповнення.

Ніщо не збирається автоматично заповнити рядок для вас, тому якщо я можу отримати кому, натиснувши "con", alt-пробіл, вниз, вниз, вниз, введіть і отримайте цитату, натиснувши "con", alt-пробіл, вниз, вниз, увійти. Я можу просто зробити це.

Ще одна річ, яку слід пам’ятати про рядкові літерали - це спосіб їх складання. Принаймні, у Delphi (яка є єдиною мовою, якою я одержима над стеком), ви заведете ваші буквари, що вискакували в стек кожної функції. Отже, багато літералів = багато функцій накладних витрат; "," у function_A - це не той самий біт пам'яті, як "," у function_B ". Для боротьби з цим існує" рядок ресурсів ", який можна побудувати і пов'язати в бік - і ось так вони роблять речі i18n (вбивство дві птахи з одним кущем). У Python усі ваші рядкові букви є об’єктами, і це насправді може здатися корисним utils.constants.COMMA.join(["some","happy","array","strings"]), але це не зоряна ідея для пунктів, що повторюються знову і знову на цій сторінці.

Але коли ми почнемо використовувати символ, інший ніж ',' для позначення коми?

Для локалізації.

В англомовних країнах символом, що розділяє цілу і дробову частини десяткової точки, є ".", Яку ми називаємо "десятковою точкою". У багатьох інших країнах символ "," і зазвичай називається еквівалентом "кома" на місцевій мові. Аналогічно, коли англомовні країни використовують "", щоб розділити групи з трьох цифр у великій кількості (наприклад, 1 000 000 на один мільйон), країни, які використовують кому як десяткову точку, використовують крапку (1.000.000).

Тож є можливість зробити константи DECIMAL_POINT та COMMA, якщо ви робите глобалізацію.