Warum sollten Programmierer ISO-Standards ignorieren? [geschlossen]

18

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.

Pieter B
quelle
64
Weil sie sie nicht kennen oder vergessen haben! Es gibt eine Unmenge von ISO-Standards ... Kennen Sie alle ISO26262?
Basile Starynkevitch
11
In der Regel führt ein Mangel an Erfahrung als Programmierer dazu, dass Sie Dinge tun, deren Konsequenzen Sie nicht erkennen. Im Allgemeinen wird sofort an ein kurzes "Ich mache es einfach so" gedacht, ohne zu beurteilen, ob bereits etwas dafür vorhanden ist oder nicht.
Dammkewl
13
Außerdem sind viele ISO-Standards nicht so einfach zu finden (normalerweise kosten sie viel Geld und es ist nicht so einfach, den neuesten Entwurf zu finden!).
Basile Starynkevitch
64
Das Tolle an Standards ist, dass es so viele zur Auswahl gibt!
Jörg W Mittag
5
Unter den seltsamsten Dingen befinden sich Programme, die einen Benutzer in einem nicht-englischen Gebietsschema dazu zwingen, seine systemweiten lokalen Einstellungen in Dezimalstellen zu ändern , um korrekt zu funktionieren. Ganz zu schweigen von Programmen, die sich weigern zu arbeiten oder einfach Müll unter nicht englischen Zeichensätzen (Russisch, Japanisch, Griechisch) produzieren, geschweige denn von RTL-Systemen (Hebräisch, Arabisch). Es geht wohl um Unwissenheit.
JensG

Antworten:

63

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).

gbjbaanb
quelle
20
Es hilft nicht, dass viele ISO-Standards teuer und / oder schwer zu bekommen sind ... Auch wenn Sie es dringend wollen!
Heltonbiker
JJJJ-MM-TT ... ist nicht teuer
Halfbit
11
@halfbit: Teuer in der Anschaffung, nicht teuer in Rechenressourcen. Im Ernst, durchsuchen Sie ihren Laden . Sie wollen den Gleitkomma-Standard ? Das sind 178 Franken.
user2357112 unterstützt Monica
32

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.

Jörg W. Mittag
quelle
9
Es kommt darauf an, mit C, C ++, Fortran ... ist die Situation ganz anders.
Vladimir F
1
Dies scheint weniger ein "Ignorieren" zu sein, als vielmehr ein "Auswählen eines Werkzeugs, das das tut, was Sie brauchen". Wenn Sie C # 5.0-Funktionen benötigen, ist die Verwendung von ISO C # nicht sinnvoller als die Verwendung von ISO C oder ISO Fortran. Das ist einfach nicht das Werkzeug, nach dem Sie gefragt haben, und ISO hat kein Äquivalent. Ihr Beispiel beinhaltet auch immer noch das Festhalten an genau definierten Standards, nur nicht an ISO-Standards.
Leushenko
3
@Leushenko Ich bin anderer Meinung; Das OP scheint der Meinung zu sein, dass Sie immer den ISO-Standards folgen sollten. +1 für ein dreistes Gegenbeispiel zu diesem "sollte".
Djechlin
3
Alles schön und gut, aber ich denke, es ging wirklich um ISO-Standards für die Datendarstellung, nicht um ISO-Standards für Programmiersprachen.
Aaronaught
4
Einige argumentieren, dass (einige) ISO-Standards ein perfektes Beispiel für das Anti-Pattern "Design by Committee" sind ...
Heltonbiker
22

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.

David
quelle
15

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).
DougM
quelle
1
Abgesehen von agilen Prozessen ist es immer billiger, ein Feature - einschließlich eines ISO-Standards - während der Entwurfs- / Spezifikationsphase einzubeziehen als während der Implementierungs- / Wartungsphase, da die Entwurfsphase nur 10% der Arbeit ausmacht. Dies ist nur eine Umkehrung des Gesetzes über die Verringerung der Retouren - ähnlich wie das Erkennen und Beheben eines Produktionsfehlers bis zu 10-mal mehr kosten kann, als wenn er als Ergebnis einer Einzel- oder Abnahmeprüfung festgestellt wurde. Wenn Sie einen guten Grund haben, den ISO-Standard überhaupt nicht zu verwenden , ist das in Ordnung. Wenn Sie sagen, dass Sie es später implementieren, lügen Sie.
Aaronaught
@Aaronaught: Meinst du, ich sollte klarstellen, dass ich mit "Konvertierung" eine externe Dateikonvertierung und kein internes Neuschreiben gemeint habe?
DougM
Wenn Sie das so gemeint haben, würde ich das mit Sicherheit klarstellen. Dies ist normalerweise nicht so einfach, da ISO mehr Standards für Datentypen als für Dateitypen definiert, und viele, wenn nicht die meisten Entwickler sich mit Anwendungen befassen, die sich nicht mit Dokumenten oder "Dateien" an sich befassen. Wenn Sie beispielsweise ein Nicht-ISO-Datum oder einen Nicht-ISO-Ländercode in einer Datenbank speichern (und das entsprechende ISO-Datum oder den entsprechenden Ländercode nicht speichern), sind die Kosten für die spätere Konvertierung sehr hoch. Wenn Sie jedoch nur über den Import eines branchenspezifischen Dateityps sprechen, können Sie dies jederzeit tun.
Aaronaught
+1 "... Sie möchten nicht unbedingt all diese Hunderte von Millionen von Feldern ändern ... bis Sie es richtig machen können." Genau.
David
14

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.

Bildbeschreibung hier eingeben

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.

Tulains Córdova
quelle
12
-1 für Ihre Karikatur erfahrener Anti-ISO-Programmierer.
Djechlin
4
@djechlin Die Sätze in Anführungszeichen sind wörtliche Ausdrücke aus den tatsächlichen Antworten in der verknüpften Frage. Sie können sogar in der Seite suchen, um zu sehen, dass dies echte Meinungen sind. Auch nicht alle erfahrenen Programmierer hassen Standards.
Tulains Córdova
2
@djechlin In meiner Antwort gibt es eine verknüpfte Frage, suchen Sie nach "Diese ähnliche Frage sehen". Das Wort "Frage" hat einen Link. Dort können Sie in Anführungszeichen nach den genauen Phrasen suchen.
Tulains Córdova
2
@djechlin der Link in der Antwort ist nicht die Frage, hier haben Sie es: programmers.stackexchange.com/questions/204340/...
Tulains Córdova
5
Auf der anderen Seite stellt die Person, die diese Antwort geschrieben hat, die verknüpfte Frage falsch dar; das Problem war es nicht mit Menschen nicht wollen , verwenden die Standards, sondern auf die mit je Stabilität eines bestimmten Standard als Primärschlüssel . Die meisten erfahrenen Datenbankdesigner werden heutzutage versuchen, Sie von "natürlichen Schlüsseln" abzulenken, da sie sich fast zwangsläufig als weniger natürlich herausstellen, als Sie ursprünglich angenommen hatten. Das ist einfach ein Argument, um das physische Datenbankdesign von den logischen Daten zu entkoppeln - niemand hat gesagt, dass er die Standards überhaupt nicht verwenden soll.
Aaronaught
10

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 )

Clément
quelle
7
Der ISO8601-Standard erlaubt sowohl die Formate JJJJ-MM-TT als auch JJJJMMTT für vollständige Darstellungen des Kalenderdatums.
Pieter B
1
Tatsächlich; daher mein schreiben "voll konform". 20140201 ist das "Basis" -Format im Standard.
Clément
8
ISO unterstützt das Basis- und das erweiterte Format. Beide Formate sind vollständig kompatibel.
Pieter B
10
ISO 8601 was published on 06/05/88 and most recently amended on 12/01/04.classic
WernerCD
8

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 (1) 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. (2)

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 :-).

Bruno
quelle
1
Ha! Weißt du was keinen Sinn ergibt? Kommas wo Dezimalstellen sein sollen! ;)
Darkwater23
@ Darkwater23 Ha, das macht mir sowieso nichts aus, es ist nur eine Konvention und es muss keinen Sinn ergeben. Es ist nur so, dass ich immer festgestellt habe, dass mm / tt / jjjj anscheinend überhaupt keine Logik hat. Warum nicht für Zeitstempel bis mm-mm-tt-hh-jjjj gehen ;-) Aber hey, ich stimme zu, das ist genau der richtige Weg es ist so, also müssen wir damit leben.
Bruno
2
@ Darkwater23 Tatsächlich verwendet ein ISO-Standard ein seltsames Unicode-Symbol (this'
:)
+1 für den Hinweis auf einen weiteren Grund, dass die Sommerzeit eine Zeitverschwendung ist.
Strg-Alt-Delor
1
@richard Die Sommerzeit ist mir auch egal, aber Programmierer sollten sicher versuchen, ihre Zeitstempel so oft wie möglich mit Zeitzoneninformationen zu speichern . Es ist nicht ungewöhnlich, dass eine Anwendung ohnehin in mehreren Zeitzonen (unabhängig von der Sommerzeit) verwendet wird. Achten Sie darauf, dass Sie beim Speichern eines Zeitstempels möglichst wenig Raum für Unklarheiten lassen. Dies sollte Teil des ursprünglichen Entwurfs sein. (Dies ist möglicherweise nicht immer zutreffend, aber im Zweifelsfall lohnt es sich immer, dies zu berücksichtigen.) Natürlich ist es ein kompliziertes Problem (zum Beispiel nicht nur +01 Stunden, sondern der Ort kann auch von Bedeutung sein, abhängig von der Verwendung).
Bruno
8

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.

MT0
quelle
7

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.

Jeff
quelle
4
Einverstanden. Ich würde mich mehr mit ISO befassen, wenn ich einen Antrag auf internationalen Verbrauch schreibe. Meine Apps für Mittelamerika benötigen weder Overhead noch Einschränkungen.
Darkwater23
4
Mit dem Vermerk "Solange die Anwendung nicht mit einer anderen Anwendung kommunizieren muss " haben Sie einen starken Grund angegeben, den ISO-Standard zu verwenden.
Tulains Córdova
5
In Ihrem Profil ist Ihr Standort nicht aufgeführt, daher weiß ich nicht, ob Ihr Beispieldatum im Januar oder Februar liegt.
Djechlin
6
-1 für die Annahme, dass keine Schnittstelle mit anderen Anwendungen besteht. Dies widerspricht der gesamten Programmindustrie.
Djechlin
18
@ Jeff: Ich habe NIEMALS ein Datum als YYYYDDMM zu einem anderen Zweck als solches codiert gesehen Anspruch einer Codierung möglich ist. Hast du?
Supercat
5

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).

vk5tu
quelle
Ich glaube, die meisten Blinden könnten jemanden dazu bringen, ihnen einen Brief vorzulesen. Es ist nicht so, dass Sie die erste Person (oder Firma) wären, die ihnen einen Brief schickt.
Wildcard
5

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).

GI8RQI
quelle
5
Es ist nicht unbedingt eine irrelevante europäische Sache, es ist eine irrelevante Sache, es sei denn, Sie müssen mit jemandem zusammenarbeiten, der ihnen folgt. Wie oft folgen Europäer ANSI-Standards, ohne dass sie einen Grund dafür haben, einen Standard zu sehen?
Stonemetal
1

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.

Jay Godse
quelle
2
Das "grobe Konsens- und Laufcode" -Modell der IETF wurde zumindest bereits 1995 aufgegeben. Ich war zu dieser Zeit zu sehr in die IETF involviert, und das Modell war "eine Spezifikation, die ich aus dem Konzept gebracht habe und nicht einmal eine Referenzimplementierung ". Es war schön, als der "Running Code" -Standard eingeführt wurde, anstatt herauszufinden, wie ein vollständig unterbestimmtes Protokoll implementiert werden kann, und es mit anderen Implementierungen zusammenarbeiten zu lassen, die genau so viel erraten mussten wie Sie.
MSW
1
Als ich mit der Verwendung von IETF-RFCs begann, verwendete ich diejenigen, die bereits vor 1995 entwickelt wurden. Die ausführenden Codespezifikationen sind die besten. Andernfalls denken sich zu viele Ingenieure von Elfenbeinturm-Geschirr Spezifikationen aus, ohne dafür verantwortlich zu sein, dass sie ausgeführt werden.
Jay Godse
1

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.

Walter Mitty
quelle
1
Ich bin nicht mit Oracle vertraut, aber wenn ich SQL Server oder MySQL verwende, verwende ich natürlich auch die entsprechenden Datumsdatentypen, wenn ich Daten speichere. Wenn Sie jedoch Abfragen mit Datumsangaben schreiben, erkennen beide sehr gut, an welcher Stelle das Datum bei der Verwendung eines Datums für das Gebietsschema angezeigt wird.
Pieter B
Das ist ein guter Punkt. Der Standard für die Speicherung und der Standard für die Schnittstelle können unterschiedlich sein.
Walter Mitty