Perché i programmatori dovrebbero ignorare gli standard ISO? [chiuso]

Una delle cose che incontro spesso sono problemi causati da programmi non conformi agli standard ISOss.

Un esempio potrebbe non essere l'utilizzo delle tabelle dei paesi ISO, ma la creazione di proprie scorciatoie, il che va bene per gli Stati Uniti (Stati Uniti) o i Paesi Bassi (NL), ma è incredibilmente sbagliato per il Regno Unito (GB, non Regno Unito) o la Spagna (ES, non SP) e molti altri paesi.

Come altro esempio, notazioni di date interne. Perché qualcuno dovrebbe mai conservare una data come il 01/02/2014? Non è del tutto chiaro se si tratti del 1 ° febbraio o del 2 gennaio, mentre se si utilizza lo standard ISO è sufficiente conservare il 01/02/2014 * ed è inequivocabilmente il 1 ° febbraio.

La mia domanda: quando e perché un programmatore dovrebbe creare i propri costrutti quando è disponibile uno standard ISO?

_{* Conservare il 01-02-2014 e formattare la data di conseguenza quando viene mostrata a un utente finale.}

Non attribuire mai alla cattiveria ciò che è adeguatamente spiegato dalla stupidità. - Robert J Hanlon .

Quello e una mancanza di comunicazione.

Quindi, non è una cospirazione del sentimento anti-ISO che induce le persone a pensare "Lo so, userò il Regno Unito invece di GB", né è un'inclinazione che "conoscono meglio", o addirittura la sensazione che lo standard non sia buono . Sarà interamente perché non sanno che è lì e dovrebbero usarlo.

Voglio dire, per alcune persone, se non è raggruppato in Visual Studio , potrebbe anche non esistere. Per altri, forse non vogliono semplicemente il set completo o è troppo difficile recuperare l'elenco definitivo, quindi si limitano a creare il proprio sottoinsieme per risolvere la loro situazione immediata. Per altri, il valore predefinito è ciò che viene utilizzato, quindi la formattazione della data non è "formattata in ISO, o anche nelle impostazioni internazionali del paese", è "formattata in qualsiasi cosa ne venga fuori" e, se ciò si adatta a loro, allora è fatto un lavoro (di solito è un critica dei programmatori americani).

Quando programma in Ruby, generalmente ignoro sempre lo standard ISO Ruby. Perché? Perché è incredibilmente restrittivo! ISO Ruby è un sottoinsieme minimo dell'intersezione di Ruby 1.8 e Ruby 1.9. L'attuale versione di Ruby, che è supportata da tutte le implementazioni di Ruby (o almeno lo sarà molto presto) è Ruby 2.1, e ha molte caratteristiche che semplificano la programmazione. La programmazione in ISO Ruby è una PITA.

Quando programma in C #, ignoro anche ISO C #, che è un sottoinsieme di C # 2.0 (e, soprattutto, la libreria di classi ISO è un sottoinsieme estremamente piccolo di .NET BCL), e invece programma in C # 5.0 e non lo uso non mi limito a utilizzare solo le librerie specificate nella CLI ISO, invece utilizzo il sottoinsieme comune di librerie disponibile in .NET 4.5.2 e Mono 3.4.0.

E quando faccio web design, preferisco di gran lunga usare HTML5 su ISO HTML (che è un piccolo sottoinsieme di HTML 4.01 Strict), ancora una volta, perché HTML5 è molto più ricco di funzionalità rispetto a un sottoinsieme limitato di una versione antica di HTML.

Quindi, ci sono buone ragioni per ignorare gli standard ISO.

Per il tuo esempio, "GB" è il prefisso internazionale per il Regno Unito. Tuttavia, "UK" era un tempo il codice standard MARC (US Library of Congress), anche se credo che sia deprecato. E IANA utilizza .ukper il dominio di primo livello per il Regno Unito.

Quindi, se qualcosa non è conforme a uno standard ISO, ciò non significa che non viene utilizzato nessuno standard; può semplicemente significare che viene utilizzato uno standard diverso . (Come notato da @ Jörg in un commento, la cosa bella degli standard è che ce ne sono così tanti tra cui scegliere.) In tal caso la domanda diventa davvero quale standard sarebbe più appropriato per il dato dominio, ambiente, ecc. ?

Le risposte a questa domanda sarebbero probabilmente in gran parte basate sull'opinione e degenererebbero rapidamente in un dibattito "religioso". Ma la conformità agli standard ISO non è necessariamente sempre la risposta migliore. Ad esempio, se un software deve interfacciarsi con i database delle biblioteche, gli standard MARC potrebbero essere una scelta più appropriata dell'ISO. Se la maggior parte del software della tua organizzazione fa le cose in un certo modo, potresti voler seguire questo approccio, almeno a breve termine - dopo tutto è lo "standard" della tua organizzazione.

Inoltre, gli standard evolvono / cambiano. Ciò che era conforme ieri potrebbe non esserlo oggi.

E, anche se non vorrei escludere l'ignoranza e / o la pigrizia come causa dei problemi segnalati ... lo sviluppatore potrebbe semplicemente non aver avuto abbastanza tempo per affrontarli.

La conformità con uno standard ISO non è sempre un'attività gratuita. Se un particolare standard non è già implementato nel toolkit che sta utilizzando, un programmatore si trova di fronte a una scelta necessaria: è più economico implementarlo correttamente ora o non implementare lo standard e gestire le conversioni in un secondo momento?

È facile dire "ehi, dovresti sempre attuare lo standard", ma tutto ha un costo. E ci sono alcuni buoni motivi per cui un programmatore potrebbe non voler implementare uno standard ISO.

• Il cliente potrebbe seguire uno standard proprietario o non ISO. Meglio attenersi allo standard che un cliente si aspetta che lasciare mal di testa non intenzionali per il tuo successore nascondendo un'implementazione aggiuntiva oltre a ciò che il cliente desidera e la tua lingua richiede.
• Potrebbero esserci molti dati esistenti e una conversione o un'interruzione del formato potrebbe non essere ancora possibile. Se hai vent'anni di contatti con i clienti e contratti con chiavi locali, non vuoi necessariamente cambiare tutte quelle centinaia di milioni di campi in date standard ISO fino a quando non riesci a farlo bene.
• L'adesione allo standard può imporre un costo maggiore di quello previsto dal beneficio. Se hai a che fare con voci interamente negli Stati Uniti, ad esempio, il codice ISO-3166-2 a cinque caratteri (US-NY) è composto da tre caratteri non necessari rispetto al codice postale americano standard (NY).

Nel caso di programmatori / progettisti di database inesperti , è perché non lo sanno. Tendono a reinventare la ruota perché non conoscono un gruppo di persone che coprono industrie, hanno già discusso del problema e hanno escogitato uno standard approvato da tutti i partecipanti, spesso dopo discussioni, revisioni, ecc. Molto lunghe. Recentemente un collaboratore il mio ha mostrato incredulità quando gli ho detto che esisteva uno standard ISO per stabilire se una determinata settimana è considerata l'ultima settimana di un anno o la prima dell'anno successivo ( ISO 8601 ). Non credeva esistesse uno standard riguardo a qualcosa di così specifico. Gli ho detto che la correttezza di molte applicazioni dipendeva da quello standard.

Nel caso di programmatori esperti / progettisti di database , la sua indifferenza è causata dal "conoscere meglio" , dalla sindrome non inventata qui e / o dalla grandiosità. Non si fidano dell'ISO o di altri organismi standard perché considerano il codice ISO "non abbastanza stabile" , il che significa che un giorno cambierà. Quindi creano i loro codici / identificatori inventati qui o auto-incrementati che ostacolano l'interoperabilità, che ignorano anche. Vedi questa domanda simile , sebbene incline alla progettazione di database. Danno ragioni come:

Potrei non volere necessariamente che il mio progetto di database dipenda da un gruppo di terze parti (IATA, ISO), indipendentemente da quanto siano stabili i loro standard. Oppure, potrei non voler dipendere da un particolare standard.

Stranamente, coloro che non rispettano gli standard utilizzano porte USB standard, acquistano DVD e BluRay di dimensioni standard e guidano auto con pneumatici conformi agli standard.

Bene, le persone tendono a ignorare gli standard ISO: ad esempio, hai scritto

se si utilizza lo standard ISO, è sufficiente conservare 20140201 * ed è inequivocabilmente il 1 ° febbraio.

ma la resa pienamente conforme a ISO8601 è in realtà 2014-02-01 . (vedi anche xkcd 1179 )

Uno dei motivi è che il dominio dell'applicazione e gli utenti potrebbero non utilizzare questi standard da soli. Anche quando alcuni domini utilizzano alcuni standard, alcuni potrebbero aver fatto scelte diverse rispetto agli standard ISO, spesso per motivi storici.

Se i tuoi utenti utilizzano già "UK" nelle loro procedure esistenti ⁽¹⁾ per fare riferimento a "Regno Unito di Gran Bretagna e Irlanda del Nord", non ha necessariamente senso utilizzare "GB" nelle loro strutture di dati (soprattutto se ciò che significa che per paese non è proprio un paese "ISO", ad esempio separare le nazioni del Regno Unito o avere sottili differenze con le Isole del Canale e così via). Certo, potresti avere un mapping tra memoria interna e presentazione, ma a volte è un po 'esagerato. Raramente stai programmando per motivi di programmazione, spesso devi adattarti al tuo ambiente. ⁽²⁾

Devi anche ricordare che questi standard si sono evoluti parallelamente al software. Spesso devi svilupparti nel contesto di altri software, alcuni dei quali potrebbero essere progettati in modo imperfetto, alcuni dei quali potrebbero ancora essere influenzati da decisioni legacy.

Anche se si guardano i formati di archiviazione dei dati interni, alcune ambiguità sono difficili da risolvere. Ad esempio, per quanto ne so, Excel utilizza un numero decimale per rappresentare i timestamp: utilizza un numero intero come numero di giorni dalla data di riferimento, quindi ciò che segue il decimale rappresenta la frazione delle 24 ore per darti l'ora. .. Il problema è che questo ti impedisce di tenere conto dei fusi orari o dell'ora legale (23h o 25h in un giorno) ed Excel convertirà qualsiasi data / ora in quel formato interno per impostazione predefinita. Sia che tu voglia utilizzare il formato ISO o meno diventa irrilevante se un altro software con cui devi lavorare non ti lascia una scelta.

_{(1) Non intendo qui "procedure di programmazione".}

_{(2) Non chiedermi perché le persone non usano tali standard nella loro vita quotidiana. Voglio dire YYYYmmdd è chiaro, gg / mm / AAAA è chiaro, ma ordinare una data con un ordine di granularità medio, piccolo e grande come mm / gg / AAAA, non ha proprio senso :-).}

Perché non dovrei usare i codici ISO 3166-1 alpha-2 del paese?

Perché io uso i codici paese STANAG 1059 ... e in quel Regno Unito è il codice per il Regno Unito (invece di GB secondo ISO 3166-1).

In alternativa, potrei usare i codici paese FIPS - di nuovo il Regno Unito è il codice paese per il Regno Unito.

Esistono molti standard (ISO e non ISO) e talvolta un determinato dominio utilizza / richiede uno standard incompatibile con lo standard ISO.

La memorizzazione di 20140201 non è affatto inequivocabile. Solo quando includi la conoscenza che segue lo standard ISO diventa inequivocabile. Lo stesso vale per il 01/02/2014: quando si include la consapevolezza che il formato è mm / gg / aaaa, è anche perfettamente inequivocabile.

Finché l'applicazione non deve interfacciarsi con altre applicazioni, qualsiasi standard ben documentato può funzionare altrettanto bene.

C'è un compromesso tra ciò che è facile per gli umani (tendo a usare 1-2-2014) e i computer (che sarebbe anche meglio con una rappresentazione binaria anziché ISO). I programmatori principianti tendono a rimanere fedeli a ciò che possono facilmente comprendere, più esperienze iniziano a vedere i vantaggi della memorizzazione orientata al computer.

Un punto non sollevato finora è l'adeguatezza culturale degli standard internazionali.

Considerare lo standard internazionale per le misurazioni. Presentiamoli agli utenti negli Stati Uniti. Non sono sicuro che tutti i tuoi utenti statunitensi saranno contenti di chilometri, chilogrammi e litri.

Considera che gli standard internazionali sono scritti dai governi. Se il governo spagnolo sceglie di non riconoscere la lingua basca, come ottiene una specifica ISO? Questo è particolarmente un problema con i dialetti e le creole dei gruppi emarginati.

Anche i codici Paese possono essere problematici: la Crimea ora ha il proprio codice Paese? Alla fine vengono trovate formule (ad esempio, "ex Repubblica jugoslava di Macedonia"), ma la tua richiesta potrebbe aver bisogno di un po 'di stand-in fino alla fine della diplomazia o della guerra.

Considera che gli standard internazionali sono scritti tenendo presente particolari applicazioni. Questi potrebbero non adattarsi completamente alla tua applicazione. Ad esempio, se stai memorizzando la lingua al fine di inviare lettere, allora potresti voler programmare chiaramente i non vedenti, anche se sono abili nel parlare, diciamo, inglese americano. Le organizzazioni statistiche sono ben consapevoli della necessità di specificare il significato esatto di una variabile (ovvero i "metadati" della variabile) quando incontrano ogni possibile caso limite durante un censimento della popolazione. Un po 'di quel rigore vale la pena per i campi del database.

L'ultimo punto è che nel fare questo tipo di scelte il tuo programma potrebbe fare una dichiarazione politica. Questa realtà può interferire con il codice più carino (ad esempio, potresti aver bisogno di più nomi di lingua per la stessa lingua).

Nella mia esperienza, i programmatori non riescono a utilizzare gli standard ISO per una serie di ragioni dichiarate, ad esempio:

• "Non sapevo che esistesse uno standard ISO" (cessa di essere un motivo valido una volta che ti è stato detto!)
• "Lo standard è inaccessibile (impossibile trovare / permettersi una copia)" (davvero ??)
• "Lo standard è troppo restrittivo" (di solito se lo standard dice "no", allora c'è una buona ragione. Ignoralo a tuo rischio e pericolo del tuo cliente!)
• "Lo standard non include la più recente funzionalità / libreria" (nessuno standard include OGNI libreria che vorresti mai usare in modo da aderire allo standard per le cose che include / cover ed essere coerente con lo standard per le cose che non lo fa)
• "Lo standard è troppo ingombrante per essere implementato" (scusa molto abusata ma vedi sotto)

L'unica ragione per cui accetto dal mio staff, in quanto non è una scusa pessima, è "lo standard in realtà non è una buona" misura "" - supportato da prove. A volte la complessità dello standard ISO applicabile è sproporzionata rispetto al problema / soluzione. A volte il contesto in cui implementerai la tua soluzione è significativamente diverso da quello assunto dallo standard. E a volte lo standard può essere migliorato - ecco come avvengono i progressi.

Più spesso, però, il mancato utilizzo dello standard ISO può essere attribuito a inesperienza, pigrizia o arroganza. Mi dispiace dire che i programmatori di lingua inglese sono particolarmente colpevoli di pigrizia per quanto riguarda l'internazionalizzazione e che i nostri colleghi statunitensi tendono a percepire l'ISO come "una cosa europea irrilevante" (si scusa con la minoranza a cui questo non si applica).

L'ISO ha molti standard. Come ha fatto CCITT / ITU. Alcuni di questi standard sono standard "aspirazionali", mentre altri sono funzionalità minime richieste. Spesso non è chiaro quale sia quale.

Ricordo che negli anni '80 mi chiedevo perché alcuni venditori di apparecchiature implementassero un sottoinsieme dello standard mentre altri vendessero un sottoinsieme diverso. È allora che è venuto fuori che gli standard sono spesso stabiliti prima che qualcosa funzioni. E i fornitori spesso scelgono deliberatamente di non implementare gli standard in modo da ostacolare l'interoperabilità, il che garantisce loro un vantaggio.

Ecco perché mi piacciono i RFC IETF. Non diventano nemmeno RFC fino a quando non ci sono 3 implementazioni indipendenti di RFC.

Se sto creando un database Oracle e desidero memorizzare le date, userò il tipo di dati Oracle DATE. Non saprò né mi preoccuperò se Oracle è conforme o meno allo standard ISO. Questo è davvero un caso della mia conformità a uno standard diverso (quello Oracle) e non tanto rispetto allo standard ISO. Vedi la risposta di @ David.

In alcuni casi, quando mi sono reso conto che esisteva uno standard ISO per qualcosa che avevo progettato, il costo di tornare indietro e riprogettare sarebbe stato proibitivo, o almeno era visto in quel modo.

A breve termine, viene prodotto più codice di lavoro utilizzando gli standard disponibili o inventandone di nuovi piuttosto che mediante un'attenta ricerca sugli standard esistenti. Il rovescio della medaglia si verifica quando l'integrazione su larga scala richiede interoperabilità. Ciò si verifica quasi sempre nel contesto di un progetto successivo.