> > 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.
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. Taki kod
jest zabroniony w procesach krytycznych. I tyle.

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. Mogą być nawet istotne dla
śladowania (ang. traceability), wiec czasami nawet nie są sprawą wolnej woli kodera.

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

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

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.

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.

--
Maciej Sobczak * http://www.inspirel.com