Por que os programadores ignorariam os padrões ISO? [fechadas]

Uma das coisas pelas quais me deparo com frequência são os problemas causados ​​por programas que não estão em conformidade com os padrões ISO.

Um exemplo seria não usar as tabelas ISO dos países, mas criar suas próprias taquigrafia, o que dá certo para os Estados Unidos (EUA) ou a Holanda (NL), mas dá espetacularmente errado para o Reino Unido (GB, não o Reino Unido) ou a Espanha (ES, não SP) e muitos outros países.

Como outro exemplo, notações internas de data. Por que alguém armazenaria uma data como 01/02/2014? Não está totalmente claro se isso é 1º de fevereiro ou 2 de janeiro, enquanto que se você usar o padrão ISO, basta armazenar 2014-02-01 * e é inequivocamente 1º de fevereiro.

Minha pergunta: quando e por que um programador deve criar suas próprias construções quando existe um padrão ISO disponível?

_{* Armazene 01-02-2014 e formate a data adequadamente ao mostrá-la a um usuário final.}

Nunca atribua à malícia aquilo que é adequadamente explicado pela estupidez. - Robert J. Hanlon .

Isso e falta de comunicação.

Portanto, não é uma conspiração de sentimentos anti-ISO que faz as pessoas pensarem "eu sei, usarei o Reino Unido em vez de GB", nem é uma tendência que "elas saibam melhor", ou mesmo uma sensação de que o padrão não seja bom . Será inteiramente porque eles simplesmente não sabem que existe e devem usá-lo.

Quero dizer, para algumas pessoas, se não estiver incluído no Visual Studio , é possível que não exista. Para outros, talvez eles simplesmente não desejem o conjunto completo ou seja muito difícil buscar a lista definitiva, então eles apenas formam seu próprio subconjunto para resolver sua situação imediata. Para outros, o padrão é o que é usado. Portanto, a formatação da data não é "formatada em ISO, ou mesmo localidade do país", é "formatada no que for necessário" e, se isso for adequado, o trabalho será feito (geralmente é um críticas de programadores americanos).

Quando programa em Ruby, geralmente sempre ignoro o padrão ISO Ruby. Por quê? Porque é incrivelmente restritivo! O ISO Ruby é um subconjunto mínimo da interseção do Ruby 1.8 e Ruby 1.9. A versão atual do Ruby, suportada por todas as implementações do Ruby (ou pelo menos será muito em breve) é Ruby 2.1, e possui muitos recursos que facilitam a programação. A programação no ISO Ruby é uma PITA.

Quando programa em C #, também ignoro o ISO C #, que é um subconjunto do C # 2.0 (e, mais importante, a ISO Class Library é um subconjunto extremamente pequeno do .NET BCL.) Em vez disso, programa em C # 5.0 e não me restrito a usar apenas as bibliotecas especificadas na ISO CLI; em vez disso, uso o subconjunto comum de bibliotecas disponíveis no .NET 4.5.2 e Mono 3.4.0.

E, ao fazer web design, prefiro usar HTML5 sobre HTML HTML (que é um pequeno subconjunto do HTML 4.01 Strict), novamente, porque o HTML5 é muito mais rico em recursos do que um subconjunto restrito de uma versão antiga do HTML.

Portanto, existem boas razões para ignorar os padrões ISO.

Por seu exemplo, "GB" é o código do país para o Reino Unido. No entanto, "Reino Unido" foi o código padrão do MARC (Biblioteca do Congresso dos EUA), embora eu acredite que isso seja preterido. E a IANA usa .ukpara o domínio de nível superior do Reino Unido.

Portanto, se algo não estiver em conformidade com um padrão ISO, isso não significa que nenhum padrão esteja sendo usado; pode simplesmente significar que um padrão diferente está sendo usado. (Como @ Jörg observou em um comentário, a coisa boa sobre os padrões é que existem tantos por onde escolher.) Nesse caso, a pergunta realmente se torna qual padrão seria o mais apropriado para o domínio, ambiente etc. do problema em questão ?

As respostas a essa pergunta provavelmente seriam amplamente baseadas em opiniões e rapidamente degenerariam em um debate "religioso". Mas a conformidade com o padrão ISO nem sempre é a melhor resposta. Por exemplo, se um software precisar fazer interface com os bancos de dados da biblioteca, os padrões MARC poderão ser uma escolha mais apropriada que a ISO. Se a maioria dos softwares da sua organização faz as coisas de uma certa maneira, você pode seguir essa abordagem, pelo menos a curto prazo - afinal, é o "padrão" da sua organização.

Além disso, os padrões evoluem / mudam. O que foi conforme ontem pode não ser hoje.

E, embora eu não queira excluir a ignorância e / ou a preguiça como a causa dos problemas que você aponta ... o desenvolvedor pode simplesmente não ter tido tempo suficiente para resolvê-los.

A conformidade com um padrão ISO nem sempre é uma atividade gratuita. Se um padrão específico ainda não foi implementado no kit de ferramentas que ela está usando, o programador se depara com uma opção necessária: é mais barato implementá-lo corretamente agora ou não implementar o padrão e lidar com as conversões posteriormente?

É fácil dizer "ei, você sempre deve implementar o padrão", mas tudo tem um custo. E há algumas boas razões pelas quais um programador pode não querer implementar um padrão ISO.

• O cliente pode estar seguindo um padrão proprietário ou não ISO. É melhor seguir o padrão que um cliente espera do que deixar dores de cabeça não intencionais para o seu sucessor, ocultando uma implementação adicional além do que o cliente deseja e do seu idioma exige.
• Pode haver uma grande quantidade de dados existentes e uma conversão ou quebra de formato ainda não é viável. Se você tiver vinte anos de contatos e contratos de clientes com datas locais, não necessariamente desejará alterar todas essas centenas de milhões de campos para datas padrão ISO até que você possa fazer o que é certo.
• A adesão ao padrão pode impor um custo maior do que o benefício oferece. Se você estiver lidando com entradas inteiramente nos Estados Unidos, por exemplo, o código ISO-3166-2 de cinco caracteres (US-NY) terá três caracteres desnecessários sobre o código postal padrão dos EUA (NY).

No caso de programadores / designers de banco de dados inexperientes , é por não saber. Eles tendem a reinventar a roda porque não conhecem um grupo de pessoas de todas as indústrias, já discutiram o assunto e criaram um padrão aprovado por todos os que participaram, geralmente após longas discussões, revisões, etc. Recentemente, um colega de trabalho um dos meus demonstrou incredulidade quando lhe disse que havia um padrão ISO sobre se uma determinada semana é considerada a última semana de um ano ou a primeira do ano seguinte ( ISO 8601 ). Ele não acreditava que existia um padrão em relação a algo tão específico. Eu disse a ele que a correção de muitos aplicativos dependia desse padrão.

No caso de programadores experientes / designers de banco de dados , isso é desconsiderado por "conhecer melhor" , síndrome não inventada aqui e / ou grandiosidade. Eles não confiam na ISO ou em qualquer outro organismo padrão porque consideram que o código ISO "não é suficientemente estável" , o que significa que um dia será alterado. Portanto, eles criam códigos / identificadores próprios, inventados aqui ou com incremento automático, dificultando a interoperabilidade, o que também desconsideram. Veja esta pergunta semelhante , ainda que inclusa no design do banco de dados. Eles dão razões como:

Talvez eu não queira necessariamente que meu design de banco de dados dependa de vários terceiros (IATA, ISO), independentemente de quão estáveis ​​sejam seus padrões. Ou talvez eu não queira depender de um padrão específico.

Curiosamente, aqueles que desconsideram os padrões usam portas USB padrão, compram DVDs e BluRays de tamanho padrão e dirigem carros com pneus que cumprem os padrões.

Bem, as pessoas tendem a ignorar os padrões ISO: por exemplo, você escreveu

se você usar o padrão ISO, basta armazenar 20140201 * e é inequivocamente 1º de fevereiro.

mas a versão totalmente compatível com ISO8601 é de fato 01/02/2014 . (veja também xkcd 1179 )

Um dos motivos é que o domínio do aplicativo e os usuários podem não usar esses padrões. Mesmo quando alguns domínios usam alguns padrões, alguns deles podem ter feito escolhas diferentes dos padrões ISO, geralmente por razões históricas.

Se seus usuários já usam "UK" em seus procedimentos existentes ⁽¹⁾ para se referir a "Reino Unido da Grã-Bretanha e Irlanda do Norte", não faz sentido usar "GB" em suas estruturas de dados (especialmente se você significa que país não é um país "ISO", por exemplo, separando nações do Reino Unido ou tendo diferenças sutis com as Ilhas do Canal e assim por diante). Obviamente, você pode ter um mapeamento entre o armazenamento interno e uma apresentação, mas às vezes é um pouco exagerado. Você raramente está programando para programar, geralmente precisa se adaptar ao seu ambiente. ²⁾

Você também deve se lembrar que esses padrões evoluíram em paralelo com o software. Você geralmente precisa desenvolver no contexto de outras partes de software, algumas das quais podem ser projetadas de maneira imperfeita, algumas das quais ainda podem ser afetadas por decisões herdadas.

Mesmo se você olhar para os formatos internos de armazenamento de dados, é difícil resolver algumas ambiguidades. Por exemplo, até onde eu sei, o Excel usa um número decimal para representar registros de data e hora: usa um número inteiro como o número de dias desde a data de referência; depois, o que é depois do decimal representa a fração das 24 horas para fornecer a hora. .. O problema é que isso impede que você leve em consideração os fusos horários ou o horário de verão (23h ou 25h em um dia), e o Excel converte qualquer data / hora para esse formato interno por padrão. Se você deseja usar o formato ISO ou não, torna-se irrelevante se outro software com o qual você tiver que trabalhar não lhe deixar uma escolha.

_{(1) Não quero dizer "procedimentos de programação" aqui.}

_{(2) Não me pergunte por que as pessoas também não usam esses padrões em suas vidas diárias. Quero dizer YYYYmmdd é claro, dd / mm / YYYY é claro, mas ordenar uma data com média, pequena e grande ordem de granularidade como mm / dd / YYYY, isso simplesmente não faz sentido :-).}

Por que eu não usaria os códigos de país ISO 3166-1 alfa-2 ?

Porque eu uso o STANAG 1059 códigos de país ... e nesse Reino Unido é o código para o Reino Unido (em vez de GB conforme ISO 3166-1).

Como alternativa, eu poderia usar o códigos de país FIPS - novamente o Reino Unido é o código de país do Reino Unido.

Existem muitos padrões (ISO e não ISO) e, às vezes, um domínio específico usa / exige um padrão que é incompatível com o padrão ISO.

Armazenar 20140201 não é nada ambíguo. Somente quando você inclui o conhecimento que está seguindo o padrão ISO, ele se torna inequívoco. O mesmo vale para 01/02/2014: quando você inclui o conhecimento de que o formato é mm / dd / aaaa, também é perfeitamente inequívoco.

Desde que o aplicativo não precise interagir com outro aplicativo, qualquer padrão bem documentado pode funcionar tão bem.

Há uma troca entre o que é fácil para humanos (eu costumo usar 1-2-2014) e computadores (quem seria melhor com uma representação binária em vez de ISO). Programadores iniciantes tendem a seguir o que conseguem entender com facilidade, mais experiências programadores começam a ver as vantagens do armazenamento orientado por computador.

Um ponto não levantado até o momento é a adequação cultural dos padrões internacionais.

Considere o padrão internacional para medições. Vamos apresentá-los a usuários nos Estados Unidos. Não sei se todos os seus usuários nos EUA ficarão felizes com quilômetros, quilogramas e litros.

Considere que os padrões internacionais são escritos pelos governos. Se o governo da Espanha optar por não reconhecer o idioma basco, como obtém uma especificação ISO? Isso é particularmente um problema com os dialetos e crioulos de grupos marginalizados.

Até os códigos dos países podem ser problemáticos: a Criméia agora tem seu próprio código? Eventualmente, são encontradas fórmulas (por exemplo, "Antiga República Jugoslava da Macedônia"), mas seu aplicativo pode precisar de algum apoio até que a diplomacia ou a guerra termine.

Considere que os padrões internacionais são escritos com aplicativos específicos em mente. Isso pode não ser totalmente adequado ao seu aplicativo. Por exemplo, se você estiver armazenando um idioma com o objetivo de enviar cartas, convém codificar os cegos de maneira distinta, mesmo que eles sejam proficientes em falar, por exemplo, inglês dos EUA. As organizações de estatística estão bem cientes da necessidade de especificar o significado exato de uma variável (também conhecido como "metadados") da variável, pois encontram todos os possíveis casos extremos durante um censo populacional. Parte desse rigor vale a pena para os campos do banco de dados.

O ponto final é que, ao fazer esse tipo de escolha, seu programa pode estar fazendo uma declaração política. Essa realidade pode mexer com o melhor código (por exemplo, você pode precisar de vários nomes de idioma para o mesmo idioma).

Na minha experiência, os programadores falham em usar os padrões ISO por várias razões declaradas, por exemplo:

• "Eu não sabia que havia um padrão ISO" (deixa de ser um motivo válido quando você é avisado!)
• "O padrão está inacessível (não é possível encontrar / comprar uma cópia)" (realmente?)
• "O padrão é muito restritivo" (geralmente se o padrão diz "não", existe um bom motivo. Ignore-o por sua conta e risco do seu cliente!)
• "O padrão não inclui a funcionalidade / biblioteca mais recente" (nenhum padrão inclui TODAS as bibliotecas que você desejará usar, portanto siga o padrão para as coisas que inclui / cubra e seja consistente com o padrão para as coisas que não)
• "O padrão é muito pesado para implementar" (desculpa muito usada, mas veja abaixo)

A única razão que aceito da minha equipe, por não ser uma desculpa esfarrapada, é "o padrão realmente não é um bom 'ajuste'" - apoiado em evidências. Às vezes, a complexidade do padrão ISO aplicável é desproporcional ao problema / solução. Às vezes, o contexto em que você implementará sua solução é significativamente diferente daquele assumido pelo padrão. E, às vezes, o padrão pode ser aprimorado - é assim que o progresso acontece.

Mais frequentemente, porém, a falha no uso do padrão ISO pode ser atribuída à inexperiência, preguiça ou arrogância. Lamento dizer que os programadores de língua inglesa são particularmente culpados de preguiça em relação à internacionalização e que nossos colegas dos EUA tendem a perceber a ISO como "uma coisa europeia irrelevante" (desculpas à minoria a quem isso não se aplica).

A ISO tem muitos padrões. Como fez o CCITT / ITU. Alguns desses padrões são "aspiracionais", enquanto outros são a funcionalidade mínima exigida. Muitas vezes não é claro qual é qual.

Lembro-me dos anos 80 perguntando por que alguns fornecedores de equipamentos implementam um subconjunto do padrão, enquanto outros fornecedores implementam um subconjunto diferente. Foi quando saiu que os padrões são frequentemente definidos antes que algo funcione. E os fornecedores geralmente escolhem deliberadamente não implementar padrões para prejudicar a interoperabilidade, o que lhes concede uma vantagem.

É por isso que eu gosto de RFCs da IETF. Eles nem se tornam RFCs até que haja três implementações independentes do RFC.

Se estou construindo um banco de dados Oracle e quero armazenar datas, vou usar o tipo de dados Oracle DATE. Não saberei nem me importarei se a Oracle está ou não em conformidade com o padrão ISO. Este é realmente um caso de minha conformidade com um padrão diferente (o Oracle) e não muito diferente do padrão ISO. Veja a resposta de @ David.

Em alguns casos, quando percebi que havia um padrão ISO para algo que eu havia projetado, o custo de voltar e redesenhar seria proibitivo ou, pelo menos, era visto dessa maneira.

No curto prazo, mais código de trabalho é produzido usando os padrões disponíveis ou inventando novos do que com uma pesquisa cuidadosa sobre os padrões existentes. A desvantagem ocorre quando a integração em grande escala requer interoperabilidade. Isso quase sempre ocorre no contexto de um projeto posterior.