Warum sollten Programmierer ISO-Standards ignorieren? [geschlossen]

Eines der Dinge, auf die ich oft stoße, sind Probleme, die durch Programme verursacht werden, die nicht den ISO-Standards entsprechen.

Ein Beispiel wäre, nicht die ISO-Ländertabellen zu verwenden, sondern eigene Abkürzungen zu bilden, was für die USA (US) oder die Niederlande (NL) in Ordnung ist, aber für das Vereinigte Königreich (GB, nicht UK) oder Spanien spektakulär falsch ist (ES, nicht SP) und viele andere Länder.

Als weiteres Beispiel interne Datumsangaben. Warum sollte jemand jemals ein Datum als 01.02.2014 speichern? Es ist völlig unklar, ob dies der 1. Februar oder der 2. Januar ist. Wenn Sie den ISO-Standard verwenden, speichern Sie nur den 01.02.2014 * und es ist eindeutig der 1. Februar.

Meine Frage: Wann und warum sollte ein Programmierer seine eigenen Konstrukte erstellen, wenn ein ISO-Standard verfügbar ist?

_{* Speichern Sie den 01.02.2014 und formatieren Sie das Datum entsprechend, wenn Sie es einem Endbenutzer anzeigen.}

Niemals der Bosheit das zuschreiben, was durch Dummheit hinreichend erklärt wird. - Robert J. Hanlon .

Das und ein Mangel an Kommunikation.

Es ist also keine Verschwörung der Anti-ISO-Stimmung, die die Leute zu dem Gedanken bringt, "Ich weiß, ich werde Großbritannien anstelle von GB verwenden", noch ist es eine Neigung, dass "sie es besser wissen", oder sogar das Gefühl, dass der Standard nicht gut ist . Es wird gänzlich sein, weil sie einfach nicht wissen, dass es da ist, und sie sollten es benutzen.

Ich meine, für einige Leute, wenn es nicht in Visual Studio gebündelt ist , könnte es genauso gut nicht existieren. Für einige andere ist es vielleicht einfach zu schwierig, die endgültige Liste abzurufen, oder sie möchten einfach nicht den vollständigen Satz. Bei anderen wird standardmäßig das verwendet, was verwendet wird. Die Datumsformatierung ist also nicht "in ISO oder sogar in der Ländereinstellung formatiert", sondern "in der Ausgabe", und wenn dies für sie geeignet ist, ist die Arbeit erledigt (dies ist normalerweise eine Kritik an amerikanischen Programmierern).

Wenn ich in Ruby programmiere, ignoriere ich im Allgemeinen immer den ISO-Ruby-Standard. Warum? Weil es unglaublich restriktiv ist! ISO Ruby ist eine minimale Teilmenge der Schnittmenge von Ruby 1.8 und Ruby 1.9. Die aktuelle Version von Ruby, die von allen Ruby-Implementierungen unterstützt wird (oder zumindest in Kürze verfügbar sein wird), ist Ruby 2.1 und verfügt über zahlreiche Funktionen, die die Programmierung erleichtern. Das Programmieren in ISO Ruby ist eine PITA.

Wenn ich in C # programmiere, ignoriere ich auch ISO C #, eine Untergruppe von C # 2.0 (und was noch wichtiger ist, die ISO-Klassenbibliothek ist eine extrem kleine Untergruppe von .NET BCL). Stattdessen programmiere ich in C # 5.0 und gebe keine Ich beschränke mich nicht darauf, nur die Bibliotheken zu verwenden, die in der ISO-CLI angegeben sind, sondern verwende stattdessen die in .NET 4.5.2 und Mono 3.4.0 verfügbare allgemeine Teilmenge von Bibliotheken.

Und wenn ich Webdesign mache, bevorzuge ich sehr viel HTML5 gegenüber ISO-HTML (was eine kleine Teilmenge von HTML 4.01 Strict ist), da HTML5 wesentlich funktionsreicher ist als eine eingeschränkte Teilmenge einer alten HTML-Version.

Es gibt also gute Gründe, ISO-Standards zu ignorieren.

In Ihrem Beispiel ist "GB" die Landesvorwahl für Großbritannien. "UK" war jedoch zu der Zeit der MARC-Standardcode (US Library of Congress), obwohl ich glaube, dass dieser veraltet ist. Und die IANA verwendet .ukfür die Top-Level-Domain für das Vereinigte Königreich.

Wenn also etwas nicht mit einem ISO-Standard übereinstimmt, heißt das nicht, dass kein Standard verwendet wird. es kann einfach bedeuten, dass ein anderer Standard verwendet wird. (Wie @ Jörg in einem Kommentar bemerkte, ist das Schöne an Standards, dass es so viele zur Auswahl gibt.) In welchem ​​Fall stellt sich die Frage, welcher Standard für die gegebene Problemdomäne, Umgebung usw. am besten geeignet wäre ?

Die Antworten auf diese Frage wären wahrscheinlich weitgehend meinungsbasiert und würden schnell zu einer "religiösen" Debatte ausarten. Die ISO-Normkonformität ist jedoch nicht immer die beste Antwort. Wenn beispielsweise eine Software mit Bibliotheksdatenbanken verbunden werden muss, sind MARC-Standards möglicherweise die geeignetere Wahl als ISO. Wenn die meisten Softwareprodukte Ihres Unternehmens bestimmte Aufgaben ausführen, sollten Sie sich zumindest kurzfristig an diesen Ansatz halten - schließlich handelt es sich um den "Standard" Ihres Unternehmens.

Auch Standards entwickeln sich / ändern sich. Was gestern konform war, darf heute nicht mehr sein.

Und obwohl ich Ignoranz und / oder Trägheit nicht als Ursache für die von Ihnen angesprochenen Probleme ausschließen möchte, hatte der Entwickler möglicherweise einfach nicht genug Zeit, um sie zu beheben.

Die Einhaltung eines ISO-Standards ist nicht immer kostenlos. Wenn ein bestimmter Standard in dem Toolkit, das sie verwendet, noch nicht implementiert ist, muss sich ein Programmierer entscheiden: Ist es billiger, diesen jetzt ordnungsgemäß zu implementieren oder den Standard nicht zu implementieren und sich später mit Konvertierungen zu befassen?

Es ist einfach zu sagen "Hey, du solltest immer den Standard implementieren", aber alles hat Kosten. Und es gibt einige gute Gründe, warum ein Programmierer möglicherweise keinen ISO-Standard implementieren möchte.

• Der Kunde kann einem firmeneigenen oder einem Nicht-ISO-Standard folgen. Es ist besser, sich an den Standard zu halten, den ein Kunde erwartet, als Ihrem Nachfolger unbeabsichtigte Kopfschmerzen zu bereiten, indem Sie eine zusätzliche Implementierung verbergen, die nicht nur den Wünschen des Kunden und den Anforderungen Ihrer Sprache entspricht.
• Möglicherweise sind sehr viele Daten vorhanden, und eine Konvertierung oder ein Formatwechsel ist möglicherweise noch nicht möglich. Wenn Sie zwanzig Jahre lang Kundenkontakte haben und Verträge mit lokalen Datumsangaben geschlossen haben, möchten Sie nicht unbedingt alle diese Hunderte Millionen Felder auf ISO-Standarddaten ändern, bis Sie es richtig machen können.
• Die Einhaltung des Standards kann mit höheren Kosten verbunden sein, als der Nutzen bietet. Wenn Sie sich beispielsweise ausschließlich mit Einträgen in den USA befassen, besteht der fünfstellige ISO-3166-2-Code (US-NY) aus drei nicht benötigten Zeichen gegenüber der US-amerikanischen Standardpostleitzahl (NY).

Im Fall von unerfahrenen Programmierern / Datenbank-Designern liegt dies daran , dass sie es nicht wissen. Sie neigen dazu, das Rad neu zu erfinden, weil sie keine Gruppe von Leuten kennen, die sich mit der Branche befassen, das Thema bereits besprochen haben und einen Standard erarbeitet haben, der von allen Beteiligten genehmigt wurde, oft nach sehr langen Diskussionen, Überarbeitungen usw. Kürzlich ein Mitarbeiter Als ich ihm erzählte, dass es einen ISO-Standard gibt, der angibt, ob eine bestimmte Woche die letzte Woche eines Jahres oder die erste des nächsten Jahres ist ( ISO 8601 ), zeigte ich mir ungläubig . Er glaubte nicht, dass es einen Standard in Bezug auf etwas so Spezifisches gab. Ich sagte ihm, dass die Richtigkeit vieler Anwendungen von diesem Standard abhänge.

Bei erfahrenen Programmierern / Datenbankdesignern ist dies eine Missachtung, die durch "besseres Wissen" , das hier nicht erfundene Syndrom und / oder Großartigkeit verursacht wird. Sie vertrauen weder ISO noch anderen Standardorganisationen, weil sie der Meinung sind, dass der ISO-Code "nicht stabil genug" ist , was bedeutet, dass er sich eines Tages ändern wird. Sie erstellen daher eigene, hier erfundene oder automatisch inkrementierte Codes / Bezeichner, die die Interoperabilität behindern und die sie ebenfalls ignorieren. Siehe diese ähnliche Frage , albeight Datenbank-Design geneigt. Sie geben Gründe wie:

Ich möchte nicht unbedingt, dass mein Datenbankdesign von einer Reihe von Drittanbietern (IATA, ISO) abhängt, unabhängig davon, wie stabil ihre Standards sind. Oder ich möchte mich überhaupt nicht auf einen bestimmten Standard verlassen.

Seltsamerweise verwenden diejenigen, die Standards missachten, Standard-USB-Anschlüsse, kaufen DVDs und Blu-Rays in Standardgröße und fahren Autos mit Reifen, die den Standards entsprechen.

Nun, die Leute neigen dazu, ISO-Standards zu ignorieren: Sie haben zum Beispiel geschrieben

Wenn Sie den ISO-Standard verwenden, speichern Sie nur 20140201 * und es ist eindeutig der 1. Februar.

Die ISO8601-konforme Wiedergabe ist jedoch tatsächlich der 01.02.2014 . (siehe auch xkcd 1179 )

Einer der Gründe ist, dass die Anwendungsdomäne und die Benutzer diese Standards möglicherweise nicht selbst verwenden. Selbst wenn einige Domänen bestimmte Standards verwenden, haben einige möglicherweise aus historischen Gründen andere Entscheidungen als die ISO-Standards getroffen.

Wenn Ihre Benutzer in ihren vorhandenen Verfahren ⁽¹⁾ bereits "UK" verwenden , um auf "Vereinigtes Königreich von Großbritannien und Nordirland" zu verweisen, ist es nicht unbedingt sinnvoll, "GB" in ihren Datenstrukturen zu verwenden (insbesondere wenn Sie dies tun) Damit ist der Begriff "Land" kein "ISO" -Land, z. Natürlich können Sie eine Zuordnung zwischen dem internen Speicher und einer Präsentation vornehmen, aber manchmal ist es etwas übertrieben. Sie programmieren selten zum Zwecke der Programmierung, sondern müssen sich häufig an Ihre Umgebung anpassen. ⁽²⁾

Sie müssen auch bedenken, dass sich diese Standards parallel zur Software entwickelt haben. Sie müssen häufig im Kontext anderer Software-Komponenten entwickeln, von denen einige möglicherweise nicht einwandfrei gestaltet sind und von denen einige möglicherweise noch von früheren Entscheidungen betroffen sind.

Selbst wenn Sie sich interne Datenspeicherformate ansehen, sind einige Unklarheiten schwer zu lösen. Zum Beispiel verwendet Excel meines Wissens eine Dezimalzahl, um Zeitstempel darzustellen: Es verwendet eine Ganzzahl als Anzahl der Tage seit einem Bezugsdatum. Was nach der Dezimalzahl steht, stellt den Bruchteil der 24 Stunden dar, um Ihnen die Stunde zu geben. Das Problem besteht darin, dass Sie auf diese Weise Zeitzonen oder die Sommerzeit (23 oder 25 Stunden pro Tag) nicht berücksichtigen können. Excel konvertiert standardmäßig Datum und Uhrzeit in dieses interne Format. Ob Sie das ISO-Format verwenden möchten oder nicht, spielt keine Rolle mehr, wenn Sie mit einer anderen Software arbeiten müssen.

_{(1) Ich meine hier nicht "Programmierverfahren".}

_{(2) Frag mich nicht, warum die Leute diese Standards auch nicht in ihrem täglichen Leben anwenden. Ich meine, JJJJMMTT ist klar, TT / MM / JJJJ ist klar, aber ein Datum mit mittlerer, kleiner und großer Granularität wie MM / TT / JJJJ zu bestellen, macht einfach keinen Sinn :-).}

Warum sollte ich keine ISO 3166-1 Alpha-2- Ländercodes verwenden?

Weil ich STANAG 1059- Ländercodes verwende ... und in diesem ist UK der Code für das Vereinigte Königreich (anstelle von GB gemäß ISO 3166-1).

Alternativ könnte ich die FIPS- Ländercodes verwenden - wieder ist Großbritannien die Landesvorwahl für das Vereinigte Königreich.

Es gibt viele Standards (ISO und Nicht-ISO) und manchmal verwendet / fordert eine bestimmte Domäne einen Standard, der mit dem ISO-Standard nicht kompatibel ist.

Die Speicherung von 20140201 ist überhaupt nicht eindeutig. Nur wenn Sie das Wissen einbeziehen, das der ISO-Norm entspricht, wird es eindeutig. Gleiches gilt für den 01.02.2014: Wenn Sie das Wissen einbeziehen, dass das Format MM / TT / JJJJ ist, ist es auch vollkommen eindeutig.

Solange die Anwendung nicht mit einer anderen Anwendung zusammenarbeiten muss, kann jeder gut dokumentierte Standard genauso gut funktionieren.

Es gibt einen Kompromiss zwischen dem, was für Menschen (ich benutze normalerweise 1-2-2014) und Computern (die mit einer binären Darstellung anstelle von ISO sogar besser dastehen würden). Programmieranfänger bleiben in der Regel bei dem, was sie leicht verstehen können, und erfahrener, dass Programmierer die Vorteile computerorientierten Speichers erkennen.

Ein Punkt, der bisher nicht angesprochen wurde, ist die kulturelle Angemessenheit internationaler Standards.

Beachten Sie den internationalen Standard für Messungen. Lassen Sie uns diese Benutzern in den Vereinigten Staaten vorstellen. Ich bin mir nicht sicher, ob alle Ihre US-Nutzer sich über Kilometer, Kilogramm und Liter freuen werden.

Bedenken Sie, dass internationale Standards von Regierungen geschrieben werden. Wenn die spanische Regierung die baskische Sprache nicht anerkennt, wie erhält sie dann eine ISO-Spezifikation? Dies betrifft insbesondere die Dialekte und Kreolen der Randgruppen.

Auch Ländercodes können problematisch sein: Bekommt die Krim jetzt einen eigenen Ländercode? Es werden schließlich Formeln gefunden (z. B. "Ehemalige jugoslawische Republik Mazedonien"), aber Ihre Bewerbung benötigt möglicherweise eine gewisse Unterstützung, bis die Diplomatie oder der Krieg zu Ende geht.

Beachten Sie, dass internationale Standards für bestimmte Anwendungen geschrieben wurden. Diese passen möglicherweise nicht vollständig zu Ihrer Anwendung. Wenn Sie beispielsweise die Sprache für das Versenden von Briefen speichern, möchten Sie den Blinden möglicherweise deutlich codieren, auch wenn er beispielsweise US-Englisch beherrscht. Statistikunternehmen sind sich der Notwendigkeit bewusst, die genaue Bedeutung einer Variablen (auch als "Metadaten" bezeichnet) anzugeben, da sie bei einer Volkszählung auf jeden möglichen Randfall stoßen. Ein Teil dieser Genauigkeit lohnt sich für Datenbankfelder.

Der letzte Punkt ist, dass Ihr Programm bei solchen Entscheidungen möglicherweise eine politische Erklärung abgibt. Diese Realität kann sich mit dem nettesten Code herumschlagen (z. B. benötigen Sie möglicherweise mehrere Sprachnamen für dieselbe Sprache).

Nach meiner Erfahrung verwenden Programmierer ISO-Standards aus einer Reihe von Gründen nicht, zB:

• "Ich wusste nicht, dass es einen ISO-Standard gibt."
• "Der Standard ist unzugänglich (kann keine Kopie finden / sich leisten)" (wirklich ??)
• "Der Standard ist zu restriktiv" (normalerweise gibt es einen guten Grund, wenn der Standard "nicht" sagt. Ignorieren Sie ihn auf Ihre und die Ihrer Kunden!)
• "Der Standard enthält nicht die neueste Funktionalität / Bibliothek" (kein Standard enthält JEDE Bibliothek, die Sie jemals verwenden möchten. Halten Sie sich also an den Standard für die Dinge, die er enthält / abdeckt, und halten Sie sich an den Standard für die Dinge das tut es nicht)
• "Der Standard ist zu umständlich umzusetzen" (stark überstrapazierte Ausrede, siehe unten)

Der einzige Grund, den ich von meinen Mitarbeitern als keine lahme Ausrede akzeptiere, ist "der Standard ist wirklich keine gute 'Passform'" - gestützt durch Beweise. Manchmal steht die Komplexität der geltenden ISO-Norm in keinem Verhältnis zum Problem / zur Lösung. Manchmal unterscheidet sich der Kontext, in dem Sie Ihre Lösung implementieren, erheblich von dem, den der Standard annimmt. Und manchmal kann der Standard verbessert werden - so kommt es zu Fortschritten.

Meistens ist die Nichtanwendung des ISO-Standards auf Unerfahrenheit, Faulheit oder Arroganz zurückzuführen. Ich bedaure zu sagen, dass englischsprachige Programmierer in Bezug auf die Internationalisierung besonders faul sind und dass unsere US-amerikanischen Kollegen ISO eher als "irrelevantes europäisches Ding" betrachten (Entschuldigung an die Minderheit, für die dies nicht zutrifft).

ISO hat viele Standards. Wie auch CCITT / ITU. Einige dieser Standards sind "ehrgeizige" Standards, während andere die minimal erforderliche Funktionalität darstellen. Es ist nicht oft klar, welches was ist.

Ich erinnere mich, dass ich in den 1980er Jahren gefragt habe, warum einige Gerätehersteller eine Untergruppe des Standards implementieren, während andere eine andere Untergruppe implementieren. Das war der Zeitpunkt, an dem sich herausstellte, dass die Standards häufig festgelegt werden, bevor etwas funktioniert. Und Anbieter entscheiden sich häufig bewusst dafür, keine Standards zu implementieren, um die Interoperabilität zu beeinträchtigen, was ihnen einen Vorteil verschafft.

Deshalb mag ich IETF RFCs. Sie werden erst dann zu RFCs, wenn drei unabhängige Implementierungen des RFC vorliegen.

Wenn ich eine Oracle-Datenbank aufbaue und Daten speichern möchte, verwende ich den Oracle-Datentyp DATE. Es ist mir egal, ob Oracle dem ISO-Standard entspricht oder nicht. Dies ist wirklich ein Fall, in dem ich mich an einen anderen Standard (den Oracle-Standard) gehalten habe und nicht so sehr vom ISO-Standard abgewichen bin. Siehe @ Davids Antwort.

In einigen Fällen waren die Kosten für die Rückgängigmachung und die Neugestaltung unerschwinglich, als mir klar wurde, dass es für etwas, das ich entworfen hatte, einen ISO-Standard gab, oder zumindest so.

Kurzfristig wird mehr Arbeitscode unter Verwendung verfügbarer Standards oder durch Erfinden neuer Standards erstellt als durch sorgfältige Erforschung vorhandener Standards. Der Nachteil tritt auf, wenn die Integration in großem Maßstab Interoperabilität erfordert. Dies geschieht fast immer im Rahmen eines späteren Projekts.