Programcılar neden ISO standartlarını yoksayar? [kapalı]

Sık sık karşılaştığım şeylerden biri, ISO standartlarına uymayan programların neden olduğu sorunlardır.

Bir örnek, ISO ülke tablolarını kullanmak değil, ABD (ABD) veya Hollanda (NL) için uygun olan ancak İngiltere (GB, İngiltere değil) veya İspanya için yanlış giden kendi kısayollarını oluşturmak olabilir. (ES, SP değil) ve diğer birçok ülke.

Başka bir örnek olarak, dahili tarih gösterimleri. Neden kimse tarihini 01/02/2014 olarak saklasın ki? Bunun 1 Şubat mı yoksa 2 Ocak mı olduğu tamamen açık değil, ISO standardını kullanırsanız sadece 2014-02-01 * depolarsınız ve açık bir şekilde 1 Şubat.

Benim sorum: Bir programcı mevcut bir ISO standardı olduğunda kendi yapılarını ne zaman ve neden oluşturmalıdır?

_{* 2014-02-01'i depolayın ve son kullanıcıya gösterildiğinde tarihi buna göre biçimlendirin.}

Aptallıkla yeterince açıklanan kötülüklere asla atfetmeyin. - Robert J Hanlon .

Bu ve iletişim eksikliği.

Bu yüzden, insanlara "Biliyorum, İngiltere yerine GB kullanacağım" diye düşündüren bir anti-ISO duyarlılığı komplosu ya da "daha iyi bildikleri" ya da standardın iyi olmadığı duygusu değil . Tamamen olacak çünkü orada olduğunu bilmiyorlar ve kullanmalılar.

Yani, bazı insanlar için, eğer Visual Studio'da paketlenmemişse , olmayabilir de. Bazıları için, belki de tam seti istemiyorlar veya kesin listeyi almak çok zor, bu yüzden acil durumlarını çözmek için kendi alt setlerini oluşturuyorlar. Diğerleri için varsayılan, kullanılan yöntemdir - bu nedenle tarih biçimlendirmesi "ISO'da veya hatta ülke yerelinde biçimlendirilmez", "ne olursa olsun biçimlendirilir" ve bu onlara uygunsa, iş yapılır (bu genellikle bir Amerikalı programcıların eleştirisi).

Ruby'de program yaptığımda genellikle ISO Ruby standardını göz ardı ederim. Neden? Çünkü inanılmaz derecede kısıtlayıcı! ISO Ruby, Ruby 1.8 ve Ruby 1.9'un kesişiminin minimal bir alt kümesidir. Tüm Ruby uygulamaları tarafından desteklenen (veya en azından çok yakında olacak) Ruby'nin mevcut sürümü Ruby 2.1'dir ve programlamayı kolaylaştıran birçok özelliğe sahiptir. ISO Ruby'de programlama bir PITA'dır.

C # programladığımda, C # 2.0'ın bir alt kümesi olan ISO C #'ı (ve daha da önemlisi, ISO Sınıf Kitaplığı .NET BCL'nin son derece küçük bir alt kümesidir) görmezden gelirim ve bunun yerine C # 5.0'da program yaparım ve Kendimi yalnızca ISO CLI'de belirtilen kitaplıkları kullanmakla kısıtlamıyorum, bunun yerine .NET 4.5.2 ve Mono 3.4.0'da bulunan kitaplıkların ortak alt kümesini kullanıyorum.

Ve web tasarımı yaparken, HTML5'i, HTML5'in eski bir sürümünün kısıtlı bir alt kümesinden çok daha fazla özellik bakımından zengin olduğu için, yine HTML5'i (HTML 4.01 Strict'nin küçük bir alt kümesi olan) ISO HTML üzerinden kullanmayı tercih ederim.

Bu nedenle, ISO standartlarını göz ardı etmek için iyi nedenler vardır.

Örneğinize göre, "GB" İngiltere için ülke kodudur. Ancak, "İngiltere" bir kerede MARC (ABD Kongre Kütüphanesi) standart koduydu, ancak bunun reddedildiğine inanıyorum. Ve IANA .ukİngiltere için en üst düzey etki alanını kullanıyor .

Dolayısıyla, bir şey ISO standardına uymuyorsa, hiçbir standardın kullanılmadığı anlamına gelmez ; sadece farklı bir standardın kullanıldığı anlamına gelebilir . (Jörg yorumunda belirtildiği @ gibi, standartları hakkında güzel bir şey seçim için bu kadar çok olmasıdır.) Bu durumda soru gerçekten hale hangi standart vb verilen sorun etki, çevre, en uygun olurdu ?

Bu soruya verilen yanıtlar büyük olasılıkla büyük ölçüde fikir temelli olacak ve hızlı bir şekilde “dini” bir tartışmaya dönüşecektir. Ancak ISO standartlarına uygunluk her zaman en iyi yanıt değildir. Örneğin, bir yazılım parçasının kütüphane veritabanlarıyla arayüz kurması gerekiyorsa, MARC standartları ISO'dan daha uygun bir seçim olabilir. Kuruluşunuzun yazılımlarının çoğu işleri belirli bir şekilde yaparsa, en azından kısa vadede bu yaklaşıma bağlı kalmak isteyebilirsiniz - sonuçta kuruluşunuzun "standardı" dır.

Ayrıca, standartlar gelişir / değişir. Dün uygun olan bugün olmayabilir.

Ve, belirttiğiniz sorunların nedeni olarak cehalet ve / veya tembellikten vazgeçmek istemememe rağmen ... geliştiricinin bunları ele almak için yeterli zamanı olmayabilir.

Bir ISO standardına uyum her zaman ücretsiz bir faaliyet değildir. Kullandığı araç setinde belirli bir standart henüz uygulanmadıysa, bir programcı gerekli bir seçimle karşı karşıyadır: Bunu şimdi doğru bir şekilde uygulamak mı yoksa standardı uygulamak mı ve daha sonra dönüşümlerle ilgilenmek mi?

"Hey, her zaman standardı uygulamalısın" demek kolaydır, ancak her şeyin bir maliyeti vardır. Ve bir programcının bir ISO standardı uygulamak istememesinin bazı iyi nedenleri vardır.

• Müşteri tescilli veya ISO dışı bir standardı izliyor olabilir. Müşterinin beklediği standarda göre, müşterinin istediği ve dilinizin gerektirdiği gibi ek bir uygulamayı gizleyerek halefiniz için istenmeyen baş ağrıları bırakmaktan daha iyidir.
• Çok fazla mevcut veri olabilir ve bir dönüşüm veya biçim kırılması henüz mümkün olmayabilir. Yerel tarih saatleriyle anahtarlanmış yirmi yıllık müşteri irtibatınız ve sözleşmeleriniz varsa, doğru şekilde yapabilene kadar bu yüz milyonlarca alanı ISO standart tarihleriyle değiştirmek istemezsiniz.
• Standarda uyulması, faydadan daha yüksek bir maliyet getirebilir. Örneğin, tamamen ABD içindeki girişlerle uğraşıyorsanız, beş karakterli ISO-3166-2 kodu (US-NY), standart ABD posta kodu (NY) üzerinde üç gereksiz karakterdir.

Deneyimsiz programcılar / veritabanı tasarımcıları söz konusu olduğunda, bilmemekten dolayıdır. Tekerleği yeniden icat etme eğilimindedirler çünkü endüstrileri kapsayan bir grup insanı bilmiyorlar, konuyu zaten tartıştılar ve çoğu zaman çok uzun tartışmalar, revizyonlar vb. Belli bir haftanın bir yılın son haftası mı yoksa bir sonraki yılın ilk haftası mı ( ISO 8601 ) kabul edildiğine dair bir ISO standardı olduğunu söylediğimde benimki inanılmazdı . Bu kadar spesifik bir şey için bir standardın var olduğuna inanmıyordu. Ona birçok uygulamanın doğruluğunun bu standarda bağlı olduğunu söyledim.

Deneyimli programcılar / veritabanı tasarımcıları durumunda , 's göz ardı neden "daha iyi bilen" değil-icat-burada sendromu ve / veya grandiyozite. ISO'ya veya başka herhangi bir standart kuruluşa güvenmiyorlar çünkü ISO kodunun "yeterince kararlı olmadığını" düşünüyorlar , yani bir gün değişecek. Böylece, kendi göz ardı ettikleri kendi burada icat edilmiş veya otomatik olarak artırılan kodları / tanımlayıcılarını oluştururlar. Veritabanı tasarımı eğimli de olsa bu benzer soruya bakın . Bunun gibi sebepler var:

Veritabanı tasarımımın, standartlarının ne kadar kararlı olduğuna bakılmaksızın, bir grup üçüncü tarafa (IATA, ISO) bağlı olmasını istemeyebilirim. Veya, belirli bir standarda hiç bağlı kalmak istemeyebilirim.

Standartları göz ardı edenler, standart USB bağlantı noktalarını kullanıyor, standart boyutlu DVD'ler ve BluRay'ler satın alıyor ve standartlara uygun lastiklerle araba kullanıyorlar.

İnsanlar ISO standartlarını göz ardı etme eğilimindedir: örneğin,

ISO standardını kullanırsanız, 20140201 * 'i depolarsınız ve bu açıkça 1 Şubat.

ancak tamamen ISO8601 uyumlu yorumlama aslında 2014-02-01'dir . (ayrıca bkz. xkcd 1179 )

Bunun nedenlerinden biri, uygulama etki alanının ve kullanıcıların bu standartları kendilerinin kullanamayacağıdır. Bazı alanlar bazı standartlar kullansa bile, bazıları çoğu zaman tarihsel nedenlerle ISO standartlarından farklı seçimler yapmış olabilir.

Kullanıcılarınız zaten mevcut prosedürlerinde ⁽ İngiltere) " Büyük Britanya ve Kuzey İrlanda Birleşik Krallığı" na başvurmak için zaten "İngiltere" kullanıyorlarsa, veri yapılarında "GB" kullanmak (özellikle de yani ülkeye göre bir "ISO" ülkesi değildir, örneğin İngiltere uluslarını birbirinden ayırmak veya Kanal Adaları ile küçük farklılıklar göstermek gibi). Tabii ki, dahili depolama bir sunum arasında bir eşleme olabilir, ancak bazen, biraz üstte. Programlama uğruna nadiren programlama yapıyorsunuz, genellikle ortamınıza uyum sağlamanız gerekiyor. ⁽²⁾

Bu standartların yazılıma paralel olarak geliştiğini de hatırlamanız gerekir. Çoğu zaman, bazılarının hala eski kararlardan etkilenmiş olabileceği diğer yazılım parçaları bağlamında geliştirmeniz gerekir.

Dahili veri depolama formatlarına baksanız bile, bazı belirsizlikleri çözmek zordur. Örneğin, bildiğim kadarıyla Excel, zaman damgalarını temsil etmek için bir ondalık sayı kullanır: bir referans tarihinden bu yana geçen gün sayısı olarak bir tam sayı kullanır, ardından ondalık sayıdan sonra saat vermek için 24 saatin kısmını temsil eder. .. Sorun, bunun saat dilimlerini veya gün ışığından yararlanma saatini (günde 23 saat veya 25 saat) dikkate almanızı engellemesidir ve Excel varsayılan olarak herhangi bir tarih / saati bu dahili biçime dönüştürür. Çalışmak zorunda olduğunuz başka bir yazılım parçası size bir seçenek bırakmıyorsa, ISO formatını kullanmak isteyip istemediğiniz önemli olmaz.

_{(1) Burada "programlama prosedürleri" demek istemiyorum.}

_{(2) Bana insanların neden bu standartları günlük yaşamlarında kullanmadığını sorma . Demek istediğim YYYYmmdd açık, gg / aa / YYYY açık, ancak mm / gg / YYYY gibi orta, küçük, büyük ayrıntı düzeyinde bir tarih sipariş etmek, bu sadece mantıklı değil :-).}

Neden ISO 3166-1 alfa-2'yi kullanmıyorum? ülke kodlarını ?

Çünkü STANAG 1059 kullanıyorum ülke kodlarını kullanıyorum ... ve İngiltere'de İngiltere'nin kodu (ISO 3166-1 uyarınca GB yerine).

Alternatif Kullanabileceğim FIPS ülke kodlarını - yine İngiltere İngiltere'nin ülke kodudur.

Birçok standart vardır (ISO ve ISO dışı) ve bazen belirli bir alan adı ISO standardıyla uyumlu olmayan bir standart kullanır / talep eder.

20140201'i saklamak hiç de net değil. Sadece ISO standardını takip eden bilgileri eklediğinizde, bu açıklığa kavuşur. Aynı şey 01/02/2014 için de geçerlidir: formatın mm / dd / yyyy olduğu bilgisini eklediğinizde, aynı zamanda mükemmel bir şekilde açıktır.

Uygulama diğer uygulamalarla arayüz kurmak zorunda olmadığı sürece, iyi belgelenmiş standartlar kadar iyi çalışabilir.

İnsanlar için kolay olan (1-2-2014 kullanma eğilimindeyim) ve bilgisayarlar (ISO yerine ikili gösterim ile daha da iyi olacak) arasında bir ödünleşim var. Acemi programcılar kolayca anlayabilecekleri şeylere bağlı kalma eğilimindedir, daha fazla deneyim programcılar bilgisayar odaklı depolamanın avantajlarını görmeye başlar.

Şimdiye kadar dile getirilmeyen bir nokta, uluslararası standartların kültürel uygunluğudur.

Ölçümler için uluslararası standardı göz önünde bulundurun. Bunları ABD'deki kullanıcılara sunalım. Tüm ABD kullanıcılarınızın kilometre, kilogram ve litre hakkında mutlu olacağından emin değilim.

Uluslararası standartların hükümetler tarafından yazıldığını düşünün. İspanya hükümeti Bask dilini tanımamayı seçerse, ISO belirtimi nasıl elde edilir? Bu özellikle marjinal grupların lehçeleri ve krizleri ile ilgili bir konudur.

Ülke kodları bile sorunlu olabilir: Kırım artık kendi ülke kodunu alıyor mu? Formüller nihayetinde bulunur (örneğin, "Eski Yugoslav Makedonya Cumhuriyeti"), ancak diplomasi veya savaş sona erene kadar başvurunuzun bir miktar beklemeye ihtiyacı olabilir.

Uluslararası standartların belirli uygulamalar dikkate alınarak yazıldığını düşünün. Bunlar uygulamanıza tam olarak uymayabilir. Örneğin, dilleri mektup gönderme amacıyla saklıyorsanız, kör bahsi, örneğin İngilizce konuşma konusunda yetkin olsalar bile, açıkça kodlamak isteyebilirsiniz. İstatistik kuruluşları, bir nüfus sayımı sırasında olası her son durumla karşılaştıklarında bir değişkenin tam anlamını (değişkenin "meta verileri" olarak) belirtme ihtiyacının farkındadır. Bu titizliklerin bazıları veritabanı alanları için de faydalıdır.

Son nokta, bu tür seçimler yaparken programınızın politik bir açıklama yapıyor olabileceğidir. Bu gerçeklik en güzel kodla uğraşabilir (örneğin, aynı dil için birden fazla dil adına ihtiyacınız olabilir).

Benim tecrübelerime göre, programcılar ISO standartlarını çeşitli nedenlerle kullanamazlar, örneğin:

• "Bir ISO standardı olduğunu bilmiyordum" (size söylendiğinde geçerli bir sebep olmaktan çıkar!)
• "Standart erişilemez (kopyasını bulamaz / karşılayamaz)" (gerçekten ??)
• "Standart çok kısıtlayıcıdır" (genellikle standart "yapma" diyorsa, bunun iyi bir nedeni vardır. Kendinizi ve müşterinizin tehlikesini göz ardı edin!)
• "Standart en son işlevselliği / kitaplığı içermez" (hiçbir standart, kullanmak istediğiniz HER kitaplığı içermez, bu nedenle içerdiği / kapsadığı şeyler için standarda uyun ve şeyler için standartla tutarlı olun değil)
• "Standart uygulanamayacak kadar hantal" (çok fazla kullanılmış bahane ama aşağıya bakınız)

Personelimden topal bir bahane olmamak için kabul etmemin tek nedeni, "standart gerçekten iyi bir" uyum "değildir - kanıtlarla desteklenmektedir. Bazen uygulanabilir ISO standardının karmaşıklığı problem / çözümle orantılı değildir. Bazen çözümünüzü uygulayacağınız bağlam, standardın varsayılanından önemli ölçüde farklıdır. Ve bazen standart geliştirilebilir - ilerleme böyle olur.

Daha sık olmamakla birlikte, ISO standardını kullanmamak deneyimsizlik, tembellik veya kibir ile ilişkilendirilebilir. İngilizce konuşan programcıların uluslararasılaşma konusunda özellikle tembellikten dolayı suçlu olduklarını ve ABD'li meslektaşlarımızın ISO'yu "alakasız bir Avrupa" olarak algılama eğiliminde olduklarından (bunun geçerli olmadığı azınlıktan özür dilerim) pişmanlık duyuyorum.

ISO'nun birçok standardı vardır. CCITT / ITU gibi. Bu standartlardan bazıları "istek uyandıran" standartlardır, diğerleri ise gerekli minimum işlevselliktir. Hangisinin olduğu genellikle açık değildir.

1980'lerde bazı ekipman satıcılarının neden standardın bir alt kümesini uygularken diğer satıcıların farklı bir alt kümeyi uyguladığını sorduğumu hatırlıyorum. İşte o zaman standartlar bir şey işe başlamadan önce belirlendi. Ve satıcılar genellikle birlikte çalışabilirliği engelleyebilmeleri için standartları uygulamamayı tercih ederler ve bu da onlara avantaj sağlar.

Bu yüzden IETF RFC'lerini seviyorum. RFC'nin 3 bağımsız uygulaması olana kadar RFC bile olmazlar.

Bir Oracle veritabanı oluşturuyorsam ve tarihleri ​​depolamak istiyorsam, Oracle DATE veri türünü kullanacağım. Oracle'ın ISO standardına uygun olup olmadığını bilmeyeceğim veya umursamıyorum. Bu gerçekten farklı bir standarda (Oracle standardına) uygunluğumun bir örneğidir ve ISO standardından çok fazla ayrılmamaktır. Bakınız @ David'in yanıtı.

Bazı durumlarda, tasarladığım bir şey için bir ISO standardı olduğunu fark ettiğimde, geri dönme ve yeniden tasarlamanın maliyeti yasaklayıcı olurdu, ya da en azından bu şekilde görülüyordu.

Kısa vadede, mevcut standartlar kullanılarak veya yeni standartlar icat edilerek mevcut standartlar üzerinde yapılan dikkatli araştırmalardan daha fazla çalışma kodu üretilir. Dezavantajı, büyük ölçekli entegrasyon birlikte çalışabilirlik gerektirdiğinde ortaya çıkar. Bu neredeyse her zaman daha sonraki bir proje bağlamında meydana gelir.