Dlaczego programiści mieliby ignorować normy ISO? [Zamknięte]

Jedną z rzeczy, na które często napotykam, są problemy powodowane przez programy niezgodne ze standardami ISO.

Jednym z przykładów byłoby nieużywanie tabel krajów ISO, ale tworzenie własnych skrótów, co jest w porządku w przypadku Stanów Zjednoczonych (USA) lub Holandii (NL), ale jest spektakularnie niewłaściwe w przypadku Wielkiej Brytanii (GB, nie Wielkiej Brytanii) lub Hiszpanii (ES, nie SP) i wiele innych krajów.

Jako kolejny przykład, wewnętrzne notacje dat. Dlaczego ktokolwiek miałby przechowywać datę 01.02.2014? Nie jest jasne, czy jest to 1 lutego czy 2 stycznia, natomiast jeśli używasz standardu ISO, po prostu przechowujesz 01.02.2014 * i jest to jednoznacznie 1 lutego.

Moje pytanie: Kiedy i dlaczego programista powinien tworzyć własne konstrukcje, gdy dostępny jest standard ISO?

_{* Zapisz 2014-02-01 i odpowiednio sformatuj datę, pokazując ją użytkownikowi końcowemu.}

Nigdy nie przypisuj złośliwości temu, co właściwie tłumaczy głupota. - Robert J Hanlon .

To i brak komunikacji.

Nie jest to więc spisek przeciwko ISO, który powoduje, że ludzie myślą: „Wiem, użyję Wielkiej Brytanii zamiast Wielkiej Brytanii”, ani też nie jest skłonność, że „oni wiedzą lepiej”, ani nawet poczucie, że standard nie jest dobry . Stanie się tak całkowicie, ponieważ oni po prostu nie wiedzą, że tam jest i powinni z niej skorzystać.

Mam na myśli, że dla niektórych osób, jeśli nie jest dołączony do Visual Studio , równie dobrze może nie istnieć. Dla niektórych innych może po prostu nie chcą pełnego zestawu lub zbyt trudno jest pobrać ostateczną listę, więc po prostu tworzą własny podzestaw, aby rozwiązać swoją bezpośrednią sytuację. W przypadku innych używane jest ustawienie domyślne - więc formatowanie daty nie jest „sformatowane w ISO, a nawet w ustawieniach regionalnych kraju”, jest „sformatowane we wszystkim, co wychodzi”, a jeśli to im odpowiada, to jest wykonane zadanie (zazwyczaj jest to krytyka amerykańskich programistów).

Kiedy programuję w Ruby, generalnie zawsze ignoruję standard ISO Ruby. Dlaczego? Ponieważ jest niesamowicie restrykcyjny! ISO Ruby to minimalny podzbiór przecięcia Ruby 1.8 i Ruby 1.9. Obecna wersja Ruby, która jest obsługiwana przez wszystkie implementacje Ruby (a przynajmniej będzie wkrótce) to Ruby 2.1 i ma wiele funkcji, które ułatwiają programowanie. Programowanie w ISO Ruby to PITA.

Kiedy programuję w C #, ignoruję również ISO C #, który jest podzbiorem C # 2.0 (a co ważniejsze, Biblioteka klas ISO jest bardzo małym podzbiorem .NET BCL), a zamiast tego programuję w C # 5.0 i nie Nie ograniczam się do korzystania tylko z bibliotek określonych w ISO CLI, zamiast tego używam wspólnego podzbioru bibliotek dostępnych w .NET 4.5.2 i Mono 3.4.0.

A podczas projektowania stron internetowych wolę używać HTML5 zamiast ISO HTML (który jest małym podzbiorem HTML 4.01 Strict), ponieważ HTML5 jest znacznie bogatszy w funkcje niż ograniczony podzbiór starożytnej wersji HTML.

Są więc dobre powody, by ignorować normy ISO.

Na przykład „GB” to kod kraju dla Wielkiej Brytanii. Jednak „Wielka Brytania” była kiedyś standardowym kodem MARC (US Library of Congress), chociaż uważam, że jest to przestarzałe. IANA korzysta .ukz domeny najwyższego poziomu w Wielkiej Brytanii.

Zatem jeśli coś nie jest zgodne ze standardem ISO, nie oznacza to, że nie stosuje się żadnego standardu; może to po prostu oznaczać, że używany jest inny standard. (Jak zauważył @ Jörg w komentarzu, miłą rzeczą w standardach jest to, że jest tak wiele do wyboru.) W takim przypadku pytanie naprawdę staje się, który standard byłby najbardziej odpowiedni dla danej problematycznej dziedziny, środowiska itp. ?

Odpowiedzi na to pytanie prawdopodobnie byłyby w dużej mierze oparte na opiniach i szybko przerodziłyby się w „religijną” debatę. Jednak zgodność z normami ISO nie zawsze jest najlepszą odpowiedzią. Na przykład, jeśli oprogramowanie wymaga połączenia z bibliotekowymi bazami danych, standardy MARC mogą być bardziej odpowiednim wyborem niż ISO. Jeśli większość oprogramowania twojej organizacji działa w określony sposób, możesz trzymać się tego podejścia, przynajmniej w perspektywie krótkoterminowej - w końcu jest to „standard” twojej organizacji.

Ponadto standardy ewoluują / zmieniają się. To, co było wczoraj zgodne, może nie być dzisiaj.

I chociaż nie chciałbym wykluczyć ignorancji i / lub lenistwa jako przyczyny problemów, na które zwracasz uwagę, deweloper może po prostu nie mieć wystarczająco dużo czasu, aby je rozwiązać.

Zgodność z normą ISO nie zawsze jest czynnością bezpłatną. Jeśli określony standard nie jest jeszcze zaimplementowany w używanym przez siebie zestawie narzędzi, programista staje przed koniecznym wyborem: czy taniej jest odpowiednio go teraz wdrożyć, czy też nie wdrożyć standardu i zająć się konwersjami później?

Łatwo powiedzieć „hej, zawsze powinieneś wdrożyć standard”, ale wszystko ma swoją cenę. I jest kilka dobrych powodów, dla których programista może nie chcieć wdrożyć normy ISO.

• Klient może postępować zgodnie z zastrzeżonym lub innym niż ISO standardem. Lepiej jest postępować zgodnie ze standardem, którego oczekuje klient, niż pozostawiać niezamierzone problemy dla następcy, ukrywając dodatkowe wdrożenie oprócz tego, czego chce klient i czego wymaga Twój język.
• Może istnieć wiele istniejących danych, a konwersja lub podział formatu może jeszcze nie być wykonalny. Jeśli masz dwadzieścia lat kontaktów z klientami i umów z lokalnymi datami, niekoniecznie chcesz zmienić wszystkie te setki milionów pól na standardowe daty ISO, dopóki nie zrobisz tego dobrze.
• Przestrzeganie standardu może wiązać się z większym kosztem niż zapewnia korzyść. Jeśli masz do czynienia z wpisami całkowicie w Stanach Zjednoczonych, na przykład pięcioznakowy kod ISO-3166-2 (US-NY) to trzy niepotrzebne znaki nad standardowym amerykańskim kodem pocztowym (NY).

W przypadku niedoświadczonych programistów / projektantów baz danych wynika to z niewiedzy. Mają tendencję do ponownego wynajdowania koła, ponieważ nie znają grupy ludzi z różnych branż, już omawiali ten problem i opracowali standard zatwierdzony przez wszystkich, którzy uczestniczyli, często po bardzo długich dyskusjach, przeglądach itp. Ostatnio współpracownik mój wykazał niedowierzanie, kiedy powiedziałem mu, że istnieje norma ISO dotycząca tego, czy dany tydzień jest uważany za ostatni tydzień roku, czy pierwszy tydzień następnego ( ISO 8601 ). Nie wierzył, że istnieje standard dotyczący czegoś tak konkretnego. Powiedziałem mu, że poprawność wielu aplikacji zależy od tego standardu.

W przypadku doświadczonych programistów / projektantów baz danych lekceważy się je z powodu „lepszego poznania” , syndromu nie-wynalezionego tutaj i / lub wspaniałości. Nie ufają ISO ani innym standardowym organom, ponieważ uważają, że kod ISO jest „niewystarczająco stabilny” , co oznacza, że ​​pewnego dnia się zmieni. Tworzą więc własne, wymyślone tutaj lub automatycznie zwiększane kody / identyfikatory utrudniające interoperacyjność, które również ignorują. Zobacz to podobne pytanie , choć skłonny jest projekt bazy danych. Podają powody, takie jak:

Niekoniecznie chcę, aby mój projekt bazy danych zależał od grupy stron trzecich (IATA, ISO), niezależnie od tego, jak stabilne są ich standardy. Lub może wcale nie chcę polegać na określonym standardzie.

Dziwne, że ci, którzy nie przestrzegają norm, używają standardowych portów USB, kupują DVD i BluRays o standardowych rozmiarach i prowadzą samochody z oponami zgodnymi ze standardami.

Cóż, ludzie zwykle ignorują normy ISO: na przykład napisałeś

jeśli używasz standardu ISO, po prostu przechowujesz 20140201 * i jest to jednoznacznie 1 lutego.

ale wersja w pełni zgodna z ISO8601 to tak naprawdę 01.02.2014 . (patrz także xkcd 1179 )

Jednym z powodów jest to, że domena aplikacji i użytkownicy mogą nie korzystać z tych standardów. Nawet jeśli niektóre domeny używają pewnych standardów, niektóre z nich mogły dokonać innych wyborów niż normy ISO, często z przyczyn historycznych.

Jeśli użytkownicy używają już „Wielkiej Brytanii” w swoich istniejących procedurach ⁽¹⁾ w odniesieniu do „Zjednoczonego Królestwa Wielkiej Brytanii i Irlandii Północnej”, niekoniecznie ma sens używanie „GB” w swoich strukturach danych (szczególnie jeśli oznacza, że ​​kraj nie jest do końca krajem „ISO”, np. dzieli narody Wielkiej Brytanii lub ma subtelne różnice z Wyspami Normandzkimi itd.). Oczywiście możesz mieć mapowanie między pamięcią wewnętrzną prezentacji, ale czasami jest to nieco przesadne. Rzadko programujesz ze względu na programowanie, często musisz dostosować się do swojego środowiska. ⁽²⁾

Musisz także pamiętać, że standardy te ewoluowały równolegle z oprogramowaniem. Często musisz się rozwijać w kontekście innych programów, z których niektóre mogą być niedokładnie zaprojektowane, a niektóre z nich mogą nadal podlegać wpływom starszych decyzji.

Nawet jeśli spojrzysz na wewnętrzne formaty przechowywania danych, pewne niejasności są trudne do rozwiązania. Na przykład, o ile mi wiadomo, Excel używa liczby dziesiętnej do reprezentowania znaczników czasu: używa liczby całkowitej jako liczby dni od daty odniesienia, a następnie to, co po przecinku reprezentuje ułamek 24 godzin, aby dać ci godzinę. Problem polega na tym, że uniemożliwia to uwzględnienie stref czasowych lub czasu letniego (23 godziny lub 25 godzin dziennie), a program Excel domyślnie skonwertuje dowolną datę / godzinę na ten format wewnętrzny. To, czy chcesz użyć formatu ISO, czy nie, nie ma znaczenia, jeśli inne oprogramowanie, z którym musisz pracować, nie pozostawia wyboru.

_{(1) Nie mam tu na myśli „procedur programowania”.}

_{(2) Nie pytaj mnie, dlaczego ludzie nie stosują tych standardów w swoim codziennym życiu. Mam na myśli, że RRRRmmdd jest jasne, dd / mm / RRRR jest jasne, ale zamawianie daty ze średnim, małym, dużym porządkiem granulacji, takim jak mm / dd / RRRR, nie ma sensu :-).}

Dlaczego nie miałbym używać kodów krajów ISO 3166-1 alpha-2 ?

Ponieważ używam kodów krajów STANAG 1059 ... i w tym Wielkiej Brytanii znajduje się kod dla Wielkiej Brytanii (zamiast GB zgodnie z ISO 3166-1).

Alternatywnie mógłbym użyć kodów krajów FIPS - znowu Wielka Brytania jest kodem kraju dla Wielkiej Brytanii.

Istnieje wiele norm (ISO i non-ISO), a czasem dana domena stosuje / żąda normy niezgodnej z normą ISO.

Przechowywanie 20140201 wcale nie jest jednoznaczne. Tylko wtedy, gdy podasz wiedzę zgodną ze standardem ISO, staje się to jednoznaczne. To samo dotyczy 01/02/2014: jeśli uwzględnisz informację, że format to mm / dd / rrrr, jest to również całkowicie jednoznaczne.

Tak długo, jak aplikacja nie musi współpracować z inną aplikacją, każdy dobrze udokumentowany standard może działać równie dobrze.

Istnieje kompromis między tym, co jest łatwe dla ludzi (zwykle używam 1-2-2014), a komputerami (dla których lepszym rozwiązaniem byłoby przedstawienie binarne zamiast ISO). Początkujący programiści zwykle trzymają się tego, co mogą łatwo zrozumieć, więcej programistów zaczyna dostrzegać zalety pamięci zorientowanej na komputer.

Nie poruszono dotychczas kwestii stosowności kulturowej standardów międzynarodowych.

Rozważ międzynarodowy standard pomiarów. Zaprezentujmy je użytkownikom w Stanach Zjednoczonych. Nie jestem pewien, czy wszyscy twoi amerykańscy użytkownicy będą zadowoleni z kilometrów, kilogramów i litrów.

Weź pod uwagę, że międzynarodowe standardy są pisane przez rządy. Jeśli rząd Hiszpanii zdecyduje się nie uznawać języka baskijskiego, to w jaki sposób uzyska specyfikację ISO? Jest to szczególnie problem z dialektami i kreolami grup marginalizowanych.

Nawet kody krajów mogą być problematyczne: czy Krym ma teraz swój własny kod kraju? Formuły zostaną ostatecznie znalezione (np. „Była Jugosłowiańska Republika Macedonii”), ale twoje podanie może wymagać pewnej rezerwy, dopóki dyplomacja lub wojna nie dobiegną końca.

Weź pod uwagę, że standardy międzynarodowe zostały napisane z myślą o konkretnych zastosowaniach. Mogą nie pasować do twojej aplikacji. Na przykład, jeśli przechowujesz język w celu wysyłania listów, możesz chcieć wyraźnie zakodować niewidomych, nawet jeśli są biegli w mówieniu, powiedzmy, amerykańskim angielskim. Organizacje statystyczne zdają sobie sprawę z potrzeby określenia dokładnego znaczenia zmiennej (znanej również jako „metadane” zmiennej), ponieważ napotykają każdy możliwy przypadek krawędzi podczas spisu ludności. Część tego rygoru jest warta pól bazy danych.

Ostatnim punktem jest to, że dokonując tego rodzaju wyborów, twój program może wydawać oświadczenie polityczne. Ta rzeczywistość może zadzierać z najpiękniejszym kodem (np. Możesz potrzebować wielu nazw języków dla tego samego języka).

Z mojego doświadczenia wynika, że ​​programiści nie stosują norm ISO z różnych określonych powodów, np .:

• „Nie wiedziałem, że istnieje norma ISO” (przestaje być ważnym powodem, gdy się o tym dowiesz!)
• „Standard jest niedostępny (nie mogę znaleźć / pozwolić sobie na kopię)” (naprawdę ??)
• „Standard jest zbyt restrykcyjny” (zwykle jeśli standard mówi „nie”, to jest dobry powód. Zignoruj ​​to na własne ryzyko i na ryzyko klienta!)
• „Standard nie obejmuje najnowszej funkcjonalności / biblioteki” (żaden standard nie zawiera KAŻDEJ biblioteki, której kiedykolwiek będziesz chciał używać, więc przestrzegaj standardu dla rzeczy, które on zawiera / obejmuje i zachowaj zgodność ze standardem dla rzeczy że tak nie jest)
• „Standard jest zbyt skomplikowany, aby go wdrożyć” (nadmiernie wykorzystywane wymówki, ale patrz poniżej)

Jedynym powodem, dla którego akceptuję od mojego personelu, że nie jest kiepską wymówką, jest „standard naprawdę nie jest dobrym„ dopasowaniem ”- poparty dowodami. Czasami złożoność obowiązującej normy ISO jest nieproporcjonalna do problemu / rozwiązania. Czasami kontekst, w którym zaimplementujesz swoje rozwiązanie, różni się znacznie od założonego przez standard. A czasem standard można poprawić - tak postępuje.

Najczęściej jednak nieprzestrzeganie normy ISO można przypisać brakowi doświadczenia, lenistwu lub arogancji. Z przykrością stwierdzam, że anglojęzyczni programiści są szczególnie winni lenistwa w odniesieniu do internacjonalizacji i że nasi amerykańscy koledzy mają tendencję do postrzegania ISO jako „nieistotnej rzeczy europejskiej” (przeprosiny dla mniejszości, której to nie dotyczy).

ISO ma wiele standardów. Podobnie jak CCITT / ITU. Niektóre z tych standardów są standardami „aspiracyjnymi”, podczas gdy inne stanowią minimalną wymaganą funkcjonalność. Często nie jest jasne, który jest który.

Pamiętam, jak w latach 80. pytano, dlaczego niektórzy dostawcy sprzętu wdrażają jeden podzbiór standardu, podczas gdy inni dostawcy wdrażają inny podzbiór. Wtedy właśnie wyszło na jaw, że standardy są często ustalane, zanim coś zadziała. A dostawcy często celowo nie wdrażają standardów, aby utrudnić interoperacyjność, co daje im przewagę.

Dlatego lubię RFC IETF. Nie stają się nawet RFC, dopóki nie będą 3 niezależnych implementacji RFC.

Jeśli buduję bazę danych Oracle i chcę przechowywać daty, użyję typu danych Oracle DATE. Nie będę wiedzieć, czy obchodzi mnie, czy Oracle jest zgodny ze standardem ISO. To naprawdę jest przypadek mojej zgodności z innym standardem (Oracle) i nie tyle odchodzenia od normy ISO. Zobacz odpowiedź @ David.

W niektórych przypadkach, zanim zdałem sobie sprawę z istnienia normy ISO dla czegoś, co zaprojektowałem, koszt powrotu i przeprojektowania byłby zbyt wysoki, a przynajmniej tak było postrzegane.

W krótkim okresie powstaje więcej działającego kodu przy użyciu dostępnych standardów lub przez wynalezienie nowych, niż przez staranne badania istniejących standardów. Minusem jest sytuacja, gdy integracja na dużą skalę wymaga interoperacyjności. Dzieje się tak prawie zawsze w kontekście późniejszego projektu.