🚀 go-pugleaf

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