eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingJak to robią w NASARe: Jak to robią w NASA
  • Data: 2019-09-04 09:53:11
    Temat: Re: Jak to robią w NASA
    Od: g...@g...com szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    W dniu środa, 4 września 2019 09:31:05 UTC+2 użytkownik Maciej Sobczak napisał:
    > > > Tak. Można stwierdzić, że w ogóle nie powinno być żadnych asercji w kodzie
    programu, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.
    > >
    > > Co za bzdura.
    > >
    > > Równie dobrze mógłbyś powiedzieć, że w kodzie programu nie powinno być żadnych
    komentarzy, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.
    >
    > Ale nie równie dobrze, bo komentarze są pożyteczne.

    Asercje też są pożyteczne.
    Asercje są formą komentarza, który dodatkowo można zweryfikować.

    > Natomiast asercje to tzw. dead code. Z założenia. To jest kod źródłowy, który
    pozostawia ślad w kodzie maszynowym, ale którego nie da się pokryć testami.

    Asercja to postawa propozycjonalna.
    Możesz sobie napisać
    #define assert(x) do {} while(0)
    i nie masz śladu w kodzie maszynowym.

    > Powtórzę dla skupienia: MISRA-C i AUTOSAR w ogóle nie poruszają tematu asercji. Co
    biorąc pod uwagę ilość innych rzeczy, które poruszają, jest co najmniej interesujące.
    > Otóż rozwiązanie tej zagadki jest bardzo proste: w kodzie krytycznym asercji się
    nie używa. Bo one stoją w konflikcie z innymi celami, które należy osiągnąć.
    >
    > > Albo że funkcje i zmienne mogą być nazwane byle jak, bo w systemie krytycznym one
    nie pełnią tam żadnej sensownej roli.
    >
    > Dryfujesz. Komentarze i nazwy są istotne dla czytelności.

    Asercje też są istotne dla czytelności.
    Po to, żeby programista wiedział:
    "aha, ten a ten warunek jest (ma być) tutaj spełniony."
    Co może być przydatne przy rozumieniu kodu, jego refaktoryzacji i debugowaniu.

    > Bo jest jeszcze taka możliwość, że potraktujesz asercje jak komentarz. To bardzo
    dobry pomysł, ale komentarze piszemy w komentarzach.

    Co jest kiepskim pomysłem, bo błędnego komentarza nie wykryjesz za pomocą narzędzia,
    a błędną asercję możesz.

    > > Wygląda na to, że wśród programistów szeroko jest rozpowszechnione błędne
    przekonanie, że asercja to "sprawdzenie czegoś w runtimie".
    >
    > Dla pewności sprawdziłem jak to opisuje standard C. Otóż właśnie dokładnie tak.

    Asercja nie jest pojęciem wprowadzonym przez standard C.

    > Oczywiście możesz sobie wyobrazić (albo nawet mieć) narzędzie, któro statycznie
    skanuje kod i sprawdza asercje (efektywnie traktując je jako static_assert), ale
    takie narzędzie potrafi też wyłuskać adnotacje z komentarzy.

    ?

    > Więc nadal twierdzę, że te asercje nie powinny być w kodzie.

    No to nie dość, że sam błędnie rozumiesz, to jeszcze próbujesz to swoje błędne
    rozumienie promować.

    > Natomiast ja chętnie stosuję asercje w skryptach testowych. Nie chce mi się używać
    wydumanych frameworków do unit testów a w testach asercje pasują idealnie.
    > Ale nie w kodzie.

    A skrypty testowe to nie kod?

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: