Nie tylko zmiennoprzecinkowe sprawy powodują problemy. Są też błędy wynikające z niepoprawnego wykonywania działań np. liczba double 1.5 zrzutowana jawnie na int wynosi 1 i środowisko nie zgłosi tu błędu, ponieważ jest to jawne rzutowanie i IDE zakłada, że wykonuje się je z pełną świadomością, a i często takie rzutowania polegające na obcięciu części liczby są przydatne i powszechnie stosowane, więc same w sobie nie są błędem programistycznym, ale jeśli wykonane bez
@Lechu1777: mała uwaga: "Więc wybór dużego typu do małej danej jest nieoptymalny," to jeszcze zależy od architektury i celów, nowe (czyli już stare procki) przy wyborze małej danej i tak stosują wyrównanie do słowa (nawet ARM) i dla takiej małej czy dużej i tak jest jedna transakcja do pamięci (sprawy cache pomijam). Generalnie masz rację i tu jeszcze dochodzi czynnik ludzki - programiści ci słabsi mają w dupie albo nie mają
maszyna uległa awarii, wyświetlając komunikat o błędzie i niepodjęciu naświetlania. Operator, przyzwyczajony do humorów urządzenia, wymusił wykonanie procedury.
@ostatni_i_sprawiedliwy jeżeli co chwila sypala błędami, dała informacje że nie naswietlała a w rzeczywistości to zrobiła to czyja wina? Owszem, operator mógł przerwać zabieg, wezwać techników, poczekać kilka tygodni a w tym czasie kolejka czekających na naświetlanie rośnie
@ostatni_i_sprawiedliwy: Nawet nie zachciałeś sprawdzić o czym rozmawiasz a się rozpisujesz.
Jeśli wymusił - to były tam mechanizmy zmuszenia urządzenia do wykonania czegoś POMIMO ALARMÓW. Jeśli takie były - skądś musiały się wziąć.
Nie alarmów tylko błędów, a tych maszyna miała 2 rodzaje, nazwijmy je zwykłym i krytycznym. Błąd zwykły wymagał wciśnięcia jednego przycisku na klawiaturze po czym maszyna resetowała się i była zdolna do dalszej pracy, błąd krytyczny wymagał resetu
@tarrin: Myślisz, że kadrę zarządzającą obchodzą jakieś praktyki czystego kodu? Ma działać i to jak najszybciej i tyle. Zresztą do niedawna praktyką było zlecanie pracy zdalnie Hindusom, więc o jakich testach tu mowa.
Komentarze (101)
najlepsze
Generalnie masz rację i tu jeszcze dochodzi czynnik ludzki - programiści ci słabsi mają w dupie albo nie mają
czy to aby błąd programisty a nie operatora?
Nie alarmów tylko błędów, a tych maszyna miała 2 rodzaje, nazwijmy je zwykłym i krytycznym. Błąd zwykły wymagał wciśnięcia jednego przycisku na klawiaturze po czym maszyna resetowała się i była zdolna do dalszej pracy, błąd krytyczny wymagał resetu
ta, ciekawe...
Nie no, wcale.
Po to się testy pisze. No, ale jak programiści są z łapanki...
CIO w tym głowa, żeby to wytłumaczyć. Jeżeli uważa, że testy są niepotrzebne to rzeczony CIO jest dupa.
Z doświadczenia ci powiem, że pisanie testów równolegle z kodem produkcyjnym(a jeszcze lepiej, używając TDD) skraca czas wytworzenia oprogramowania.
Hindusom
Mówili o tym na studiach xd
Komentarz usunięty przez moderatora