Чому програмісти ігнорують стандарти ISO? [зачинено]

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

Одним із прикладів може бути не використання таблиць країн ISO, а складання власних стенограмів, що нормально для США (США) або Нідерландів (NL), але йде зовсім не так для Великобританії (GB, а не Великобританії) або Іспанії (ES, а не SP) та багато інших країн.

В якості іншого прикладу внутрішні позначення дат. Чому хтось зберігав би дату як 02.02.2014? Зовсім незрозуміло, чи це буде 1 лютого чи 2 січня, тоді як якщо ви використовуєте стандарт ISO, ви просто зберігаєте 2014-02-01 * і це однозначно 1 лютого.

Моє запитання: Коли і навіщо програміст повинен складати власні конструкції, коли є стандарт ISO?

_{* Зберігайте 2014-02-01 і відформатуйте дату відповідно, показуючи її кінцевому користувачеві.}

Ніколи не приписуйте злобі те, що адекватно пояснюється дурістю. - Роберт Дж Хенлон .

Те, і відсутність спілкування.

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

Я маю на увазі, для деяких людей, якщо це не в комплекті з Visual Studio , воно також може не існувати. Для деяких інших, можливо, вони просто не хочуть повного набору або занадто складно отримати остаточний список, тому вони просто складають свій підмножину для вирішення своєї негайної ситуації. Для інших стандартним є те, що звикає - тому форматування дат не "відформатоване в ISO, або навіть в локальній країні", воно "форматоване в тому, що виходить", і якщо це їм підходить, то це робота виконана (зазвичай це критика американських програмістів).

Коли я програмую в Ruby, я завжди ігнорую стандарт ISO Ruby. Чому? Бо це неймовірно обмежує! ISO Ruby - це мінімальний підмножина перетину Ruby 1.8 та Ruby 1.9. Поточна версія Ruby, яка підтримується всіма реалізаціями Ruby (або, принаймні, буде дуже скоро), є Ruby 2.1, і вона має безліч функцій, які спрощують програмування. Програмування в ISO Ruby - це PITA.

Коли я програмую на C #, я також ігнорую ISO C #, що є підмножиною C # 2.0 (і що ще важливіше, бібліотека класів ISO - надзвичайно малий підмножина .NET BCL), і замість цього я програмую на C # 5.0, і я не не обмежую себе використовувати лише ті бібліотеки, які вказані в ISO CLI, натомість я використовую загальний підмножина бібліотек, доступна в .NET 4.5.2 та Mono 3.4.0.

І, роблячи веб-дизайн, я дуже вважаю за краще використовувати HTML5 над ISO HTML (що є невеликим підмножиною HTML 4.01 Strict), знову ж таки, тому що HTML5 набагато більш багатий на функції, ніж обмежений підмножина старовинної версії HTML.

Отже, є вагомі причини ігнорування стандартів ISO.

Згідно з вашим прикладом, "GB" - код країни для Сполученого Королівства. Однак "Великобританія" була свого часу стандартним кодом MARC (Бібліотека Конгресу США), хоча я вважаю, що це застаріло. І IANA використовує .ukдомен верхнього рівня для Сполученого Королівства.

Отже, якщо щось не відповідає стандарту ISO, це не означає, що жоден стандарт не використовується; це може просто означати, що використовується інший стандарт. (Як зазначає @ Jörg в коментарі, приємно, що у стандартах є те, що їх можна вибрати.) У такому випадку справді виникає питання, який стандарт буде найбільш відповідним для даної проблемної області, середовища тощо ?

Відповіді на це питання, ймовірно, значною мірою ґрунтуються на думці та швидко перероджуються у "релігійну" дискусію. Але відповідність стандарту ISO не завжди є найкращою відповіддю. Наприклад, якщо частина програмного забезпечення потребує взаємодії з базами даних бібліотеки, стандарти MARC можуть бути більш правильним вибором, ніж ISO. Якщо більшість програмного забезпечення вашої організації робить щось певним чином, ви, можливо, захочете дотримуватися такого підходу, принаймні в короткостроковій перспективі - це "стандарт" вашої організації, зрештою.

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

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

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

Неважко сказати "ей, ти завжди повинен впроваджувати стандарт", але все має вартість. І є кілька вагомих причин, чому програміст може не захотіти впроваджувати стандарт ISO.

• Замовник може дотримуватися фірмового або не-ISO стандарту. Краще прискорити стандарт, якого очікує клієнт, ніж залишити ненавмисні головні болі для свого наступника, сховавши додаткову реалізацію, окрім того, що хоче клієнт та потрібна ваша мова.
• Можливо, існує велика кількість існуючих даних, і конверсія чи перерва формату ще не є можливим. Якщо у вас є двадцять років контактів із клієнтами та укладені договори з місцевими датами, вам не обов’язково потрібно змінювати всі ці сотні мільйонів полів на стандартні дати ISO, поки ви не зможете це зробити правильно.
• Дотримання стандарту може спричинити більшу вартість, ніж надає вигода. Наприклад, якщо ви маєте на увазі записи повністю в межах США, наприклад, п'яти символьний код ISO-3166-2 (US-NY) - це три непотрібні символи над стандартним поштовим індексом США (NY).

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

Що стосується досвідчених програмістів / дизайнерів баз даних , це ігнорування викликане "знанням кращого" , не вигаданим тут синдромом та / або грандіозністю. Вони не довіряють ISO або будь-яким іншим стандартним органам, оскільки вважають, що ISO код "недостатньо стабільний" , тобто він колись зміниться. Таким чином, вони створюють власні, винайдені тут або автопоглиблені коди / ідентифікатори, що заважають сумісності, яких вони також нехтують. Дивіться подібне запитання , хоча схильний дизайн бази даних схильний. Вони наводять такі причини:

Я не обов'язково хочу, щоб дизайн моєї бази даних залежав від групи третіх сторін (IATA, ISO), незалежно від того, наскільки стабільні їх стандарти. Або я не хочу взагалі залежати від певного стандарту.

Як не дивно, ті, хто нехтує стандартами, використовують стандартні порти USB, купують DVD та BluRays стандартного розміру та керують автомобілями з шинами, які відповідають стандартам.

Ну, люди схильні ігнорувати стандарти ISO: наприклад, ви писали

якщо ви використовуєте стандарт ISO, ви просто зберігаєте 20140201 *, і це однозначно 1 лютого.

але повністю відповідає сумісному стандарту ISO8601 - це фактично 2014-02-01 . (див. також xkcd 1179 )

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

Якщо ваші користувачі вже використовують "Великобританію" у своїх існуючих процедурах ⁽¹⁾ для позначення "Сполучене Королівство Великобританії та Північної Ірландії", це не обов'язково має сенс використовувати "GB" у своїх структурах даних (особливо якщо ви мається на увазі, що країна не є цілком "ISO" країною, наприклад, відокремлюючи країни Великої Британії або маючи тонкі відмінності з Каналськими островами тощо. Звичайно, у вас може бути відображення презентації між внутрішнім сховищем, але іноді це трохи вище. Ви рідко програмуєте заради програмування, вам часто доводиться адаптуватися до свого оточення.⁽²⁾

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

Навіть якщо ви дивитесь на внутрішні формати зберігання даних, деякі неясності важко вирішити. Наприклад, наскільки я знаю, Excel використовує десяткове число для позначення часових позначок: воно використовує ціле число як кількість днів з моменту опорної дати, то те, що після десяткової представляє частку за 24 години, щоб дати вам годину. .. Проблема полягає в тому, що це заважає вам брати до уваги часові пояси або перехід на літній час (23 години або 25 годин на день), і Excel перетворить будь-яку дату / час у цей внутрішній формат за замовчуванням. Незалежно від того, хочете ви використати формат ISO чи ні, це не має значення, якщо інша частина програмного забезпечення, з яким вам доведеться працювати, не залишає вам вибору.

_{(1) Я тут не маю на увазі "процедури програмування".}

_{(2) Не питайте мене, чому люди також не використовують ці стандарти у своєму повсякденному житті. Я маю на увазі YYYYmmdd зрозумілий, dd / mm / YYYY зрозумілий, але замовлення дати середнім, малим, великим порядком деталізації, наприклад, mm / dd / YYYY, це просто не має сенсу :-).}

Чому б я не використовував ISO 3166-1 альфа-2 коди країн ?

Тому що я використовую STANAG 1059 коди країн ... і в цій Великобританії код Великобританії (замість ГБ відповідно до ISO 3166-1).

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

Існує багато стандартів (ISO і не-ISO), а іноді певний домен використовує / вимагає стандарт, несумісний зі стандартом ISO.

Зберігання 20140201 зовсім не однозначне. Тільки коли ви включаєте знання, які відповідають стандарту ISO, це стає однозначним. Те ж саме стосується і 02.02.2014: коли ви включаєте знання про те, що формат є мм / дд / ггг, це також абсолютно однозначно.

Поки додаток не повинен взаємодіяти з іншим додатком, будь-який добре задокументований стандарт може працювати так само добре.

Існує компроміс між тим, що легко для людей (я схильний використовувати 1-2-2014) та комп’ютерами (хто навіть краще, якщо двійкове представлення замість ISO). Новачки-програмісти, як правило, дотримуються того, що вони легко зрозуміють, більше досвіду програмісти починають бачити переваги комп'ютерно орієнтованого зберігання.

Точка, яку не піднімали досі, - це культурна відповідність міжнародних стандартів.

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

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

Навіть коди країн можуть бути проблематичними: чи Крим зараз отримує власний код країни? Формули в кінцевому підсумку знайдуться (наприклад, "Колишня югославська республіка Македонія"), але вашій заяві може знадобитися певна підтримка, поки не закінчиться дипломатія чи війна.

Вважайте, що міжнародні стандарти пишуться з урахуванням конкретних заявок. Вони можуть не повністю відповідати вашій заявці. Наприклад, якщо ви зберігаєте мову з метою надсилання листів, то, можливо, ви захочете чітко кодувати сліпих, навіть якщо вони володіють англійською мовою США. Організації зі статистики добре знають необхідність уточнення точного значення змінної (також "метаданих" змінної), оскільки вони стикаються з усіма можливими кращими випадками під час перепису населення. Частина цієї суворості цілком корисна для полів бази даних.

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

На мій досвід, програмісти не використовують стандартів ISO з різних заявлених причин, наприклад:

• "Я не знав, що існує стандарт ISO" (перестає бути поважною причиною, як тільки вам кажуть!)
• "Стандарт недоступний (не можу знайти / дозволити собі копію)" (дійсно ??)
• "Стандарт є занадто обмежуючим" (зазвичай, якщо стандарт говорить "не", то є вагомі причини. Ігноруйте це на вашу користь і на замовника!)
• "Стандарт не включає в себе найновішу функціональність / бібліотеку" (жоден стандарт не включає ВСЕ БІБЛІОТЕКУ, яку ви коли-небудь захочете використовувати, щоб дотримуватися стандарту для речей, які він НЕ включає / охоплює, і відповідати стандарту для речей що це не так)
• "Стандарт занадто громіздкий для впровадження" (сильно завищений привід, але дивіться нижче)

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

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

ISO має безліч стандартів. Як це робив CCITT / ITU. Деякі з цих стандартів є "амбіційними" стандартами, а інші - мінімально необхідними функціональними можливостями. Не часто зрозуміло, що є.

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

Ось чому мені подобаються IETF RFC. Вони навіть не стають RFC, поки не існують 3 незалежні реалізації RFC.

Якщо я будую базу даних Oracle і хочу зберігати дати, я буду використовувати тип даних Oracle DATE. Я не знаю, чи не хвилюється, чи відповідає Oracle стандарту ISO чи ні. Це дійсно випадок моєї відповідності іншому стандарту (Oracle) і не стільки відходу від стандарту ISO. Дивіться @ відповідь Девіда.

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

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