Почему программисты игнорируют стандарты ISO? [закрыто]

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

Одним из примеров может быть не использование таблиц стран ИСО, а составление их собственных сокращений, что хорошо для Соединенных Штатов (США) или Нидерландов (Нидерланды), но идет совершенно неправильно для Соединенного Королевства (Великобритании, а не Великобритании) или Испании. (ES, а не SP) и много других стран.

В качестве другого примера, обозначения внутренней даты. Зачем кому-то хранить дату как 01/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, и я не не ограничиваю себя использованием только библиотек, указанных в CLI ISO, вместо этого я использую общее подмножество библиотек, доступных в .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-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, часто по историческим причинам.

Если ваши пользователи уже используют «Великобритания» в своих существующих процедурах ⁽¹⁾ для обозначения «Соединенное Королевство Великобритании и Северной Ирландии», не обязательно имеет смысл использовать «ГБ» в своих структурах данных (особенно если имеется в виду, что страна не совсем страна "ISO", например, разделение наций Великобритании или тонкие различия с Нормандскими островами и т. д.). Конечно, у вас может быть отображение между внутренним хранилищем и презентацией, но иногда это немного излишне. Вы редко программируете ради программирования, вам часто приходится приспосабливаться к вашей среде. ⁽²⁾

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

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

_{(1) Я не имею в виду «процедуры программирования» здесь.}

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

Почему бы мне не использовать коды стран ISO 3166-1 alpha-2 ?

Потому что я использую коды стран STANAG 1059 ... и в этом Соединенном Королевстве есть код Соединенного Королевства (вместо ГБ в соответствии с ISO 3166-1).

В качестве альтернативы я мог бы использовать коды стран FIPS - опять же, Великобритания - это код страны для Соединенного Королевства.

Существует много стандартов (ISO и не-ISO), и иногда определенный домен использует / требует стандарт, который несовместим со стандартом ISO.

Хранение 20140201 вовсе не однозначно. Только когда вы включаете знания, которые соответствуют стандарту ISO, оно становится однозначным. То же самое относится и к 02.02.2014: когда вы включаете знание, что форматом является мм / дд / гггг, это также совершенно однозначно.

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

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

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

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

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

Даже коды стран могут быть проблематичными: теперь Крым получает свой собственный код страны? Формулы в конечном итоге найдены (например, «Бывшая югославская Республика Македония»), но ваше заявление может нуждаться в некоторой замене, пока дипломатия или война не закончится.

Учтите, что международные стандарты написаны с учетом конкретных приложений. Они могут не полностью соответствовать вашему приложению. Например, если вы храните язык для отправки писем, вы можете четко кодировать слепых, даже если они владеют, скажем, американским английским языком. Статистические организации хорошо осведомлены о необходимости указания точного значения переменной (так называемые «метаданные» переменной), поскольку они сталкиваются с каждым возможным крайним случаем во время переписи населения. Часть этой строгости хорошо подходит для полей базы данных.

И последнее: при выборе такого рода ваша программа может делать политическое заявление. Эта реальность может испортить самый красивый код (например, вам может потребоваться несколько названий языков для одного и того же языка).

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

• «Я не знал, что существует стандарт ISO» (перестает быть веской причиной, как только вы сказали!)
• «Стандарт недоступен (не могу найти / позволить себе копию)» (правда ??)
• «Стандарт слишком ограничительный» (обычно, если стандарт говорит «нет», то есть веская причина. Игнорируйте его на свой страх и риск своего клиента!)
• «Стандарт не включает новейшую функциональность / библиотеку» (ни один стандарт не включает КАЖДУЮ библиотеку, которую вы когда-либо захотите использовать, поэтому придерживайтесь стандарта для вещей, которые он включает / покрывает и соответствует стандарту для вещей что это не так)
• «Стандарт слишком громоздок для реализации» (извините, но слишком часто, но смотрите ниже)

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

Чаще всего отказ от использования стандарта ISO может объясняться неопытностью, ленью или высокомерием. С сожалением могу сказать, что англоязычные программисты особенно виноваты в лени в отношении интернационализации и что наши американские коллеги склонны воспринимать ISO как «неуместную европейскую вещь» (извинения меньшинству, к которому это не относится).

ИСО имеет много стандартов. Как и МККТТ / МСЭ. Некоторые из этих стандартов являются «желательными» стандартами, а другие - минимально необходимыми функциями. Не часто понятно, что есть что.

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

Вот почему мне нравятся RFC IETF. Они даже не становятся RFC, пока не появятся 3 независимых реализации RFC.

Если я создаю базу данных Oracle и хочу сохранить даты, я собираюсь использовать тип данных Oracle DATE. Я не буду знать или беспокоиться о том, соответствует ли Oracle стандарту ISO. Это на самом деле случай моего соответствия другому стандарту (Oracle) и не слишком большой отход от стандарта ISO. Смотрите ответ @ Дэвида.

В некоторых случаях, к тому времени, когда я понял, что для чего-то, что я спроектировал, был стандарт ISO, стоимость возврата и перепроектирования была бы непомерно высокой или, по крайней мере, была бы такой.

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