Pourquoi les programmeurs ignoreraient-ils les normes ISO? [fermé]

Une des choses que je rencontre est souvent des problèmes causés par les programmes qui ne sont pas conformes à la norme ISO normess.

Un exemple serait de ne pas utiliser les tableaux de pays ISO mais de créer leurs propres raccourcis, ce qui va bien pour les États-Unis (États-Unis) ou les Pays-Bas (NL) mais va de manière spectaculaire pour le Royaume-Uni (GB, pas UK) ou l'Espagne (ES, pas SP) et beaucoup d'autres pays.

Comme autre exemple, les notations de date internes. Pourquoi quelqu'un enregistrerait-il une date au 01/02/2014? Il n'est pas clair si c'est le 1er février ou le 2 janvier, alors que si vous utilisez la norme ISO, vous stockez simplement le 2014-02-01 * et c'est sans ambiguïté le 1er février.

Ma question: quand et pourquoi un programmeur devrait-il créer ses propres constructions alors qu'une norme ISO est disponible?

_{* Stockez le 2014-02-01 et formatez la date en conséquence lorsque vous la montrez à un utilisateur final.}

N'attribuez jamais à la malveillance ce qui s'explique adéquatement par la stupidité. - Robert J. Hanlon .

Ça, et un manque de communication.

Donc, ce n'est pas une conspiration de sentiments anti-ISO qui fait penser aux gens "Je sais, je vais utiliser le Royaume-Uni au lieu de GB", ni une tendance à "qu'ils connaissent mieux", ni même le sentiment que la norme n'est pas bonne . Ce sera entièrement parce qu'ils ne savent tout simplement pas que c'est là et qu'ils devraient l'utiliser.

Je veux dire, pour certaines personnes, s'il n'est pas intégré à Visual Studio , il pourrait tout aussi bien ne pas exister. Pour certains autres, peut-être qu'ils ne veulent tout simplement pas l'ensemble complet ou qu'il est trop difficile de récupérer la liste définitive, alors ils ne font que créer leur propre sous-ensemble pour résoudre leur situation immédiate. Pour d'autres, la valeur par défaut est ce qui est utilisé - donc le formatage de la date n'est pas "formaté en ISO, ou même dans les paramètres régionaux du pays", il est "formaté dans tout ce qui sort" et si cela leur convient, alors c'est du travail fait (c'est généralement un critique des programmeurs américains).

Lorsque je programme en Ruby, j'ignore généralement toujours la norme ISO Ruby. Pourquoi? Parce que c'est incroyablement restrictif! ISO Ruby est un sous-ensemble minimal de l'intersection de Ruby 1.8 et Ruby 1.9. La version actuelle de Ruby, qui est prise en charge par toutes les implémentations Ruby (ou du moins le sera très bientôt) est Ruby 2.1, et elle possède de nombreuses fonctionnalités qui facilitent la programmation. La programmation en ISO Ruby est un PITA.

Lorsque je programme en C #, j'ignore également ISO C #, qui est un sous-ensemble de C # 2.0 (et plus important encore, la bibliothèque de classes ISO est un sous-ensemble extrêmement petit du .NET BCL), et à la place je programme en C # 5.0 et je ne Je ne me limite pas à utiliser uniquement les bibliothèques spécifiées dans l'ISO CLI, à la place j'utilise le sous-ensemble commun de bibliothèques disponibles dans .NET 4.5.2 et Mono 3.4.0.

Et lorsque je fais de la conception Web, je préfère de loin utiliser HTML5 plutôt qu'ISO HTML (qui est un petit sous-ensemble de HTML 4.01 Strict), encore une fois, car HTML5 est beaucoup plus riche en fonctionnalités qu'un sous-ensemble restreint d'une ancienne version de HTML.

Il y a donc de bonnes raisons d'ignorer les normes ISO.

Selon votre exemple, "GB" est le code de pays pour le Royaume-Uni. Cependant, "UK" était en même temps le code standard MARC (US Library of Congress), bien que je pense que ce soit obsolète. Et l'IANA utilise .ukpour le domaine de premier niveau pour le Royaume-Uni.

Donc, si quelque chose n'est pas conforme à une norme ISO, cela ne signifie pas qu'aucune norme n'est utilisée; cela peut simplement signifier qu'une norme différente est utilisée. (Comme @ Jörg l'a noté dans un commentaire, la bonne chose à propos des normes est qu'il y a tellement de choix.) Dans ce cas, la question devient vraiment quelle norme serait la plus appropriée pour le domaine de problème, l'environnement, etc. ?

Les réponses à cette question seraient probablement largement basées sur l'opinion et dégénéreraient rapidement en un débat "religieux". Mais la conformité aux normes ISO n'est pas nécessairement toujours la meilleure réponse. Par exemple, si un logiciel doit s'interfacer avec des bases de données de bibliothèque, les normes MARC pourraient être un choix plus approprié que l'ISO. Si la plupart des logiciels de votre organisation font les choses d'une certaine manière, vous voudrez peut-être vous en tenir à cette approche, au moins à court terme - c'est la «norme» de votre organisation, après tout.

De plus, les normes évoluent / changent. Ce qui était conforme hier peut ne pas l'être aujourd'hui.

Et, même si je ne voudrais pas exclure l'ignorance et / ou la paresse comme cause des problèmes que vous signalez ... le développeur n'a peut-être tout simplement pas eu assez de temps pour les résoudre.

La conformité à une norme ISO n'est pas toujours une activité gratuite. Si une norme particulière n'est pas déjà implémentée dans la boîte à outils qu'elle utilise, un programmeur est confronté au choix nécessaire: est-ce moins cher de l'implémenter correctement maintenant, ou de ne pas implémenter la norme et de gérer les conversions plus tard?

Il est facile de dire "hé, vous devez toujours appliquer la norme", mais tout a un coût. Et il y a de bonnes raisons pour lesquelles un programmeur peut ne pas vouloir implémenter une norme ISO.

• Le client peut suivre une norme propriétaire ou non ISO. Mieux vaut tenir compte de la norme à laquelle un client s'attend que de laisser des maux de tête involontaires à votre successeur en cachant une mise en œuvre supplémentaire en plus de ce que le client veut et de votre langue.
• Il peut y avoir beaucoup de données existantes et une conversion ou un saut de format peut ne pas être encore possible. Si vous avez vingt ans de contacts avec les clients et de contrats avec des dates-heures locales, vous ne voulez pas nécessairement changer tous ces centaines de millions de champs en dates standard ISO jusqu'à ce que vous puissiez le faire correctement.
• L'adhésion à la norme peut imposer un coût plus élevé que l'avantage prévu. Si vous traitez des entrées entièrement aux États-Unis, par exemple, le code ISO-3166-2 à cinq caractères (US-NY) correspond à trois caractères inutiles par rapport au code postal américain standard (NY).

Dans le cas des programmeurs / concepteurs de bases de données inexpérimentés , c'est parce qu'ils ne savent pas. Ils ont tendance à réinventer la roue parce qu'ils ne connaissent pas un groupe de personnes couvrant des industries, ont déjà discuté de la question et ont proposé une norme approuvée par tous ceux qui ont participé, souvent après de très longues discussions, révisions, etc. Récemment, un collègue J'ai fait preuve d'incrédulité lorsque je lui ai dit qu'il existait une norme ISO pour savoir si une semaine donnée était considérée comme la dernière semaine d'une année ou la première de l'année suivante ( ISO 8601 ). Il ne croyait pas qu'il existait une norme concernant quelque chose d'aussi spécifique. Je lui ai dit que l'exactitude de nombreuses demandes dépendait de cette norme.

Dans le cas des programmeurs / concepteurs de bases de données expérimentés , c'est le mépris causé par le «savoir mieux» , le syndrome non inventé ici et / ou la grandiosité. Ils ne font pas confiance à l'ISO ou à tout autre organisme normalisé car ils considèrent que le code ISO n'est "pas assez stable" , ce qui signifie qu'il changera un jour. Ils créent donc leurs propres codes / identificateurs inventés ici ou auto-incrémentés qui entravent l'interopérabilité, ce qu'ils ignorent également. Voir cette question similaire , bien que la conception de la base de données soit inclinée. Ils donnent des raisons comme:

Je ne veux pas nécessairement que ma conception de base de données dépende d'un tas de tiers (IATA, ISO), quelle que soit la stabilité de leurs normes. Ou, je ne veux pas du tout dépendre d'une norme particulière.

Curieusement, ceux qui ne respectent pas les normes utilisent des ports USB standard, achètent des DVD et BluRays de taille standard et conduisent des voitures avec des pneus conformes aux normes.

Eh bien, les gens ont tendance à ignorer les normes ISO: par exemple, vous avez écrit

si vous utilisez la norme ISO, vous stockez simplement 20140201 * et c'est sans équivoque le 1er février.

mais le rendu entièrement conforme à ISO8601 est en fait 2014-02-01 . (voir aussi xkcd 1179 )

L'une des raisons est que le domaine d'application et les utilisateurs peuvent ne pas utiliser eux-mêmes ces normes. Même lorsque certains domaines utilisent certaines normes, certains d'entre eux ont pu faire des choix différents des normes ISO, souvent pour des raisons historiques.

Si vos utilisateurs utilisent déjà "UK" dans leurs procédures existantes ⁽¹⁾ pour faire référence à "Royaume-Uni de Grande-Bretagne et d'Irlande du Nord", cela n'a pas nécessairement de sens d'utiliser "GB" dans leurs structures de données (surtout si ce que vous par pays n'est pas tout à fait un pays "ISO", par exemple la séparation des nations britanniques ou des différences subtiles avec les îles anglo-normandes, etc.). Bien sûr, vous pourriez avoir un mappage entre le stockage interne d'une présentation, mais parfois, c'est un peu exagéré. Vous programmez rarement pour des raisons de programmation, vous devez souvent vous adapter à votre environnement. ⁽²⁾

Vous devez également vous rappeler que ces normes ont évolué en parallèle avec les logiciels. Vous devez souvent vous développer dans le contexte d'autres logiciels, dont certains peuvent être imparfaitement conçus, dont certains peuvent encore être affectés par des décisions héritées.

Même si vous regardez les formats de stockage de données internes, certaines ambiguïtés sont difficiles à résoudre. Par exemple, pour autant que je sache, Excel utilise un nombre décimal pour représenter les horodatages: il utilise un entier comme nombre de jours depuis une date de référence, puis ce qui est après la décimale représente la fraction des 24 heures pour vous donner l'heure. .. Le problème est que cela vous empêche de prendre en compte les fuseaux horaires ou l'heure d'été (23h ou 25h par jour), et Excel convertira toute date / heure en ce format interne par défaut. Que vous souhaitiez ou non utiliser le format ISO devient sans importance si un autre logiciel avec lequel vous devez travailler ne vous laisse pas le choix.

_{(1) Je ne parle pas ici de "procédures de programmation".}

_{(2) Ne me demandez pas non plus pourquoi les gens n'utilisent pas ces normes dans leur vie quotidienne. Je veux dire YYYYmmdd est clair, dd / mm / YYYY est clair, mais commander une date avec un ordre de granularité moyen, petit et grand comme mm / dd / YYYY, cela n'a tout simplement pas de sens :-).}

Pourquoi ne devrais-je pas utiliser les codes de pays ISO 3166-1 alpha-2 ?

Parce que j'utilise les codes de pays STANAG 1059 ... et que le Royaume-Uni est le code du Royaume-Uni (au lieu de GB selon ISO 3166-1).

Sinon, je pourrais utiliser les codes de pays FIPS - encore une fois, UK est le code de pays pour le Royaume-Uni.

Il existe de nombreuses normes (ISO et non ISO) et parfois un domaine particulier utilise / exige une norme incompatible avec la norme ISO.

Le stockage de 20140201 n'est pas du tout sans ambiguïté. Ce n'est que lorsque vous incluez les connaissances qui suivent la norme ISO que cela devient sans ambiguïté. Il en va de même pour le 01/02/2014: lorsque vous incluez la connaissance que le format est mm / jj / aaaa, il est également parfaitement sans ambiguïté.

Tant que l'application n'a pas à s'interfacer avec une autre application, n'importe quelle norme bien documentée peut fonctionner aussi bien.

Il y a un compromis entre ce qui est facile pour les humains (j'ai tendance à utiliser 1-2-2014) et les ordinateurs (qui seraient encore mieux avec une représentation binaire au lieu d'ISO). Les programmeurs débutants ont tendance à s'en tenir à ce qu'ils peuvent facilement comprendre, plus les programmeurs commencent à voir les avantages du stockage orienté ordinateur.

Un point qui n'a pas été soulevé jusqu'à présent est l'adéquation culturelle des normes internationales.

Considérez la norme internationale pour les mesures. Présentons-les aux utilisateurs aux États-Unis. Je ne suis pas sûr que tous vos utilisateurs américains seront satisfaits des kilomètres, des kilogrammes et des litres.

Considérez que les normes internationales sont écrites par les gouvernements. Si le gouvernement espagnol choisit de ne pas reconnaître la langue basque, comment obtient-il une spécification ISO? C'est particulièrement un problème avec les dialectes et les créoles des groupes marginalisés.

Même les codes de pays peuvent être problématiques: la Crimée a-t-elle désormais son propre code de pays? Des formules sont finalement trouvées (par exemple, "ex-République yougoslave de Macédoine"), mais votre candidature peut nécessiter une certaine place jusqu'à la fin de la diplomatie ou de la guerre.

Considérez que les normes internationales sont écrites avec des applications particulières à l'esprit. Ceux-ci peuvent ne pas correspondre entièrement à votre application. Par exemple, si vous stockez une langue en vue d'envoyer des lettres, vous souhaiterez peut-être coder les aveugles de manière distincte, même s'ils sont capables de parler, par exemple, l'anglais américain. Les organismes statistiques sont bien conscients de la nécessité de spécifier la signification exacte d'une variable (alias les «métadonnées» de la variable) car ils rencontrent tous les cas marginaux possibles lors d'un recensement de la population. Une partie de cette rigueur vaut bien pour les champs de base de données.

Le dernier point est qu'en faisant ce genre de choix, votre programme peut faire une déclaration politique. Cette réalité peut perturber le plus beau du code (par exemple, vous pouvez avoir besoin de plusieurs noms de langue pour la même langue).

D'après mon expérience, les programmeurs ne parviennent pas à utiliser les normes ISO pour diverses raisons, par exemple:

• "Je ne savais pas qu'il y avait une norme ISO" (cesse d'être une raison valable une fois qu'on vous le dit!)
• "La norme est inaccessible (ne peut pas trouver / se permettre une copie)" (vraiment ??)
• «La norme est trop restrictive» (généralement si la norme dit «non», alors il y a une bonne raison. Ignorez-la à vos risques et périls!)
• "La norme n'inclut pas la dernière fonctionnalité / bibliothèque" (aucune norme n'inclut TOUTES les bibliothèques que vous voudrez utiliser, alors respectez la norme pour les choses qu'elle comprend / couvre et soyez cohérent avec la norme pour les choses que ce n'est pas le cas)
• "La norme est trop lourde à mettre en œuvre" (excuse largement surutilisée mais voir ci-dessous)

La seule raison que j'accepte de la part de mon personnel, comme n'étant pas une excuse boiteuse, est "la norme n'est vraiment pas un bon" ajustement "" - étayée par des preuves. Parfois, la complexité de la norme ISO applicable est hors de proportion avec le problème / la solution. Parfois, le contexte dans lequel vous implémenterez votre solution est considérablement différent de celui supposé par la norme. Et parfois, la norme peut être améliorée - c'est ainsi que les progrès se produisent.

Plus souvent qu'autrement, le non-respect de la norme ISO peut être attribué à l'inexpérience, à la paresse ou à l'arrogance. J'ai le regret de dire que les programmeurs anglophones sont particulièrement coupables de paresse en matière d'internationalisation et que nos collègues américains ont tendance à percevoir l'ISO comme "une chose européenne non pertinente" (excuses à la minorité à laquelle cela ne s'applique pas).

L'ISO a beaucoup de normes. Tout comme le CCITT / UIT. Certaines de ces normes sont des normes "ambitieuses", tandis que d'autres sont des fonctionnalités minimales requises. Il n'est pas souvent clair qui est lequel.

Je me souviens dans les années 80 de demander pourquoi certains fournisseurs d'équipement implémentent un sous-ensemble de la norme alors que d'autres fournisseurs implémentent un sous-ensemble différent. C'est à ce moment-là que les normes sont souvent fixées avant que quelque chose fonctionne. Et les fournisseurs choisissent souvent délibérément de ne pas mettre en œuvre de normes afin de nuire à l'interopérabilité, ce qui leur confère alors un avantage.

C'est pourquoi j'aime les RFC IETF. Ils ne deviennent même pas des RFC tant qu'il n'y a pas 3 implémentations indépendantes de la RFC.

Si je crée une base de données Oracle et que je souhaite stocker des dates, je vais utiliser le type de données Oracle DATE. Je ne saurai pas ou ne me soucierai pas si Oracle est conforme ou non à la norme ISO. Il s'agit vraiment d'un cas de ma conformité à une norme différente (celle d'Oracle) et non pas tellement à l'écart de la norme ISO. Voir la réponse de @ David.

Dans certains cas, au moment où je me suis rendu compte qu'il y avait une norme ISO pour quelque chose que j'avais conçu, le coût du retour en arrière et de la refonte aurait été prohibitif, ou du moins était vu de cette façon.

À court terme, plus de code de travail est produit en utilisant les normes disponibles ou en en inventant de nouvelles que par une recherche minutieuse des normes existantes. L'inconvénient se produit lorsqu'une intégration à grande échelle nécessite une interopérabilité. Cela se produit presque toujours dans le contexte d'un projet ultérieur.