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

18

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.

Pieter B.
źródło
64
Ponieważ ich nie znają lub zapomnieli o nich! Istnieją tysiące standardów ISO .... Czy znasz wszystkie ISO26262?
Basile Starynkevitch
11
Zwykle brak doświadczenia jako programisty powoduje, że robisz rzeczy, których nie zdajesz sobie sprawy z konsekwencji. Ogólnie rzecz biorąc, szybkie „po prostu zrobię to w ten sposób” przychodzi na myśl natychmiast, bez żadnej oceny, czy istnieje już coś takiego.
dammkewl
13
Ponadto wiele norm ISO nie jest tak łatwych do znalezienia (zwykle kosztują duże dolary, a znalezienie najnowszej wersji roboczej nie jest takie proste!).
Basile Starynkevitch
64
Wspaniałą rzeczą w standardach jest to, że jest tak wiele do wyboru!
Jörg W Mittag
5
Do najdziwniejszych rzeczy należą programy, które zmuszają użytkownika nieanglojęzycznego do użytkownika w języku innym niż angielski do zmiany lokalnych ustawień systemowych na dziesiętne w celu poprawnego działania. Nie mówiąc już o programach, które odmawiają pracy lub po prostu produkują śmieci w nieanglojęzycznych zestawach znaków (rosyjski, japoński, grecki), nie mówiąc już o systemach RTL (hebrajski, arabski). Chyba wiąże się to z ignorancją.
JensG

Odpowiedzi:

63

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).

gbjbaanb
źródło
20
Nie pomaga to, że wiele norm ISO jest drogich i / lub trudnych do uzyskania ... Nawet jeśli bardzo chcesz!
heltonbiker
rrrr-mm-dd ... nie jest drogi
półbitek
11
@halfbit: Drogie w zakupie, nie drogie w zasobach obliczeniowych. Poważnie, przejrzyj ich sklep . Chcesz standard zmiennoprzecinkowy ? To będzie 178 franków.
user2357112 obsługuje Monikę
32

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.

Jörg W Mittag
źródło
9
Zależy, w przypadku C, C ++, Fortran ... sytuacja jest zupełnie inna.
Vladimir F
1
Wydaje się to mniej przypominać „ignorowanie” zgodnie z intencją pytania, a bardziej „wybieranie narzędzia, które robi to, czego potrzebujesz”. Jeśli potrzebujesz funkcji C # 5.0, nie ma większego sensu stosowanie ISO C # niż ISO C lub ISO Fortran; to po prostu nie narzędzie, o które prosiłeś, a ISO nie ma odpowiednika. Twój przykład nadal wiąże się z przestrzeganiem dobrze zdefiniowanych standardów, po prostu nie ISO.
Leushenko
3
@Leushenko Nie zgadzam się; wydaje się, że OP powinien zawsze przestrzegać norm ISO, kropka. +1 za bezczelny kontrprzykład do tego „powinien”.
djechlin
3
Wszystko dobrze i dobrze, ale myślę, że pytanie naprawdę dotyczyło norm ISO dotyczących reprezentacji danych, a nie norm ISO dla języków programowania.
Aaronaught
4
Niektórzy twierdzą, że (niektóre) normy ISO są doskonałym przykładem anty-wzoru „Design by Committee” ...
heltonbiker
22

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ć.

David
źródło
15

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).
DougM
źródło
1
Pomijając zwinne procesy, zawsze taniej jest zawrzeć dowolną cechę - w tym normę ISO - na etapie projektowania / specyfikacji niż na etapie wdrażania / konserwacji, ponieważ faza projektowania stanowi jedynie 10% pracy. Jest to tylko odwrócenie prawa malejących zwrotów - podobnie do tego, w jaki sposób identyfikacja i usunięcie wady produkcyjnej może kosztować nawet 10-krotnie więcej niż w przypadku stwierdzenia w wyniku testu jednostkowego lub testu akceptacyjnego. Jeśli masz stałe powód nie przy użyciu standardu ISO w ogóle , to jest w porządku; jeśli powiesz, że wdrożysz go później, kłamiesz.
Aaronaught
@Aaronaught: Czy uważasz, że powinienem wyjaśnić, że przez „konwersję” miałem na myśli konwersję plików zewnętrznych, a nie wewnętrzne ponowne zapisywanie?
DougM
Jeśli to miałeś na myśli, z pewnością wyjaśnię. Zwykle nie jest to takie proste, ponieważ ISO określa więcej standardów dla typów danych niż typów plików, a wielu, jeśli nie większość programistów, zajmuje się aplikacjami, które same nie zajmują się dokumentami ani „plikami”. Jeśli na przykład przechowujesz datę lub kod kraju spoza ISO (i nie przechowujesz odpowiedniej daty ISO lub kodu kraju), wówczas koszt konwersji w dół będzie bardzo wysoki. Z drugiej strony, jeśli po prostu mówisz o zaimportowaniu jakiegoś typu pliku specyficznego dla branży, możesz to zrobić za każdym razem.
Aaronaught
+1 „... niekoniecznie chcesz zmienić te setki milionów pól ... dopóki nie zrobisz tego dobrze”. Dokładnie.
David
14

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.

wprowadź opis zdjęcia tutaj

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.

Tulains Córdova
źródło
12
-1 dla karykatury doświadczonych programistów przeciw ISO.
djechlin
4
@djechlin Wyrażenia w cytatach są dosłowne z prawdziwych odpowiedzi na powiązane pytanie. Możesz nawet wyszukiwać na stronie, aby zobaczyć, że są to prawdziwe opinie. Również nie wszyscy doświadczeni programiści nienawidzą standardów.
Tulains Córdova
2
@djechlin W mojej odpowiedzi jest powiązane pytanie, poszukaj „zobacz to podobne pytanie”. Słowo „pytanie” ma link. Tam możesz wyszukać dokładne frazy w cudzysłowie.
Tulains Córdova
2
@djechlin link jest w odpowiedzi, nie w pytaniu, oto masz: programmers.stackexchange.com/questions/204340/…
Tulains Córdova
5
Z drugiej strony osoba, która napisała tę odpowiedź, wprowadza w błąd powiązane pytanie; problemem nie było to, że ludzie nie chcieli używać standardów, ale w zależności od stabilności określonego standardu jako klucza podstawowego . Obecnie najbardziej doświadczeni projektanci baz danych będą próbować oderwać cię od „naturalnych kluczy”, kropka, ponieważ prawie nieuchronnie okazują się mniej naturalne, niż pierwotnie zakładałeś. To po prostu argument za oddzieleniem fizycznego projektu bazy danych od danych logicznych - nikt nie powiedział, że w ogóle nie stosuje standardów.
Aaronaught
10

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 )

Łaskawy
źródło
7
Standard ISO8601 zezwala zarówno na formaty RRRR-MM-DD, jak i RRRRMMDD na pełne przedstawienie dat kalendarzowych.
Pieter B,
1
W rzeczy samej; stąd moje pismo „w pełni zgodne”. 20140201 to format „podstawowy” w standardzie.
Clément,
8
ISO pozwala na format podstawowy i rozszerzony, oba są w pełni zgodne.
Pieter B,
10
ISO 8601 was published on 06/05/88 and most recently amended on 12/01/04.classic
WernerCD
8

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 (1) 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. (2)

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 :-).

Bruno
źródło
1
Ha! Wiesz co nie ma sensu? Przecinki, w których powinny być dziesiętne! ;)
Darkwater23,
@ Darkwater23 Ha, nie mam nic przeciwko temu, tak czy inaczej, to tylko konwencja i nie musi mieć sensu. Po prostu zawsze znajdowałem, że mm / dd / RRRR wydawało się całkowicie pozbawione logiki, dlaczego więc nie posunąć się do mm-MM-dd-HH-RRRR dla znaczników czasu ;-) Ale hej, zgadzam się, po prostu tak jest tak jest, więc musimy z tym żyć.
Bruno,
2
@ Darkwater23 W rzeczywistości norma ISO używa dziwnego symbolu Unicode (this :) do separatora dziesiętnego na klawiaturach i myślałem, że zwykłe znaczniki ( ') zostały również znormalizowane do grupowania cyfr (chociaż nie mogę go teraz znaleźć)
Izkata
+1 za wskazanie innego powodu, dla którego czas letni jest stratą czasu.
ctrl-alt-delor
1
@richard Nie koniecznie mam nic przeciwko DST, ale na pewno programiści powinni dążyć do przechowywania swoich znaczników czasu z informacjami o strefie czasowej, o ile to możliwe. W każdym razie aplikacja jest używana w wielu strefach czasowych (niezależnie od czasu letniego), dzięki czemu pozostawiasz tak mało miejsca na dwuznaczności, kiedy przechowujesz znacznik czasu, który powinien być częścią początkowego projektu. (Może nie zawsze ma to zastosowanie, ale wątpliwe, zawsze warto to wziąć pod uwagę.) Oczywiście jest to skomplikowany problem (na przykład nie tylko +01 godziny, ale lokalizacja może mieć znaczenie, w zależności od zastosowania).
Bruno,
8

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.

MT0
źródło
7

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.

Jeff
źródło
4
Zgoda. Byłbym bardziej zaniepokojony ISO, gdybym pisał wniosek o międzynarodową konsumpcję. Moje aplikacje dla Ameryki Środkowej nie wymagają narzutu ani ograniczeń.
Darkwater23,
4
Pisząc „Tak długo, jak aplikacja nie musi się łączyć z inną aplikacją”, masz silny powód, aby stosować standard ISO.
Tulains Córdova
5
Twój profil nie podaje Twojej lokalizacji, więc nie wiem, czy Twoja próbna data przypada w styczniu czy lutym.
djechlin
6
-1 przy założeniu, że nie będzie współpracować z innymi aplikacjami. Jest to sprzeczne z całą branżą programistyczną.
djechlin
18
@Jeff: NIGDY nie widziałem daty kodowanej jako RRRRDDMM w żadnym innym celu niż twierdzenie, że takie kodowanie jest możliwe. Czy ty?
supercat
5

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).

vk5tu
źródło
Wierzę, że większość niewidomych byłaby w stanie zmusić kogoś do przeczytania listu do nich. To nie tak, że jako pierwsza osoba (lub firma) wyślesz im list.
Wildcard
5

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).

GI8RQI
źródło
5
Niekoniecznie jest to nieistotna rzecz europejska, jest nieistotna, chyba że musisz współpracować z kimś, kto ją śledzi. Jak często Europejczycy przestrzegają norm ANSI bez powodu innego niż hej wyglądają na standardy?
stonemetal
1

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.

Jay Godse
źródło
2
Model „surowego konsensusu i działającego kodu” IETF został porzucony od co najmniej już w 1995 roku. Byłem zbyt zaangażowany w IETF w tamtej epoce, a model ten był „specyfikacją, którą kichnąłem, a nawet implementacją referencyjną „. Fajnie było, gdy istniał standard „działającego kodu” zamiast zastanawiać się, jak zaimplementować całkowicie niedokładny protokół i sprawić, by działał z innymi implementacjami, które musiały odgadnąć tak samo jak ty.
msw
1
Kiedy zacząłem używać RFC IETF, korzystałem z tych opracowanych na długo przed 1995 rokiem. Specyfikacje działającego kodu są najlepsze. W przeciwnym razie kończy się zbyt wielu inżynierów tworzących wykresy z kości słoniowej, którzy marzą o specyfikacjach bez odpowiedzialności za ich uruchomienie.
Jay Godse,
1

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.

Walter Mitty
źródło
1
Nie jestem zaznajomiony z Oracle, ale podczas korzystania z SQL Server lub MySQL ja również używam ich odpowiednich typów danych daty podczas przechowywania dat. Ale pisząc zapytania z datami, oboje bardzo dobrze rozpoznają yyyymmdd w przypadku trafienia lub pominięcia, gdy używasz daty regionalnej.
Pieter B
Trafne spostrzeżenie. Standard przechowywania i standard interfejsu mogą być inne.
Walter Mitty,