Jakie są rzeczywiste zalety statycznej analizy kodu?

Narzędzia takie jak pc-lint lub QAC mogą być używane do przeprowadzania statycznej analizy kodu na podstawie kodu.

Z mojego doświadczenia wynika, że ​​analiza statyczna często powoduje ogromny hałas, tj. Ostrzeżenia o rzeczach, które nie są prawdziwymi błędami, ale w jakiś sposób naruszają jedną z reguł w danym zestawie reguł. Wyłączenie niektórych reguł (na dobre w zestawie reguł lub poprzez specjalne komentarze w kodzie) może być bardzo uciążliwym procesem.

Jakie są rzeczywiste zalety statycznej analizy kodu?

Pracowałem w miejscu, które korzystało z komercyjnego systemu analizy kodu statycznego o nazwie Coverity Prevent, a to było niesamowite! Jest naprawdę wyrafinowany i inteligentny.

Wrzuciliśmy do niego około 18 GB zarówno otwartego, jak i zastrzeżonego kodu C i C ++, który prześledziłby ścieżki kodu i szybko znalazłby subtelne błędy, których odnalezienie zajęłoby człowiekowi wieczność. Świetnie sprawdzał się także w wyszukiwaniu rzeczy, które zwykle byłyby Heisenbugs.

Działa co kilka dni z naszą bazą kodu, a fajną funkcją było to, że mogliśmy powiedzieć: „To nie jest tak naprawdę błąd” i zapamięta to w przyszłości.

Gotcha jest taka, że ​​ubezpieczenie jest naprawdę drogie. Nie publikują kosztów, ale mam wrażenie, że w przypadku projektów komercyjnych zaczyna się od setek tysięcy dolarów rocznie. Ale prawdopodobnie zaoszczędziło nam to konieczności zatrudniania całej gamy programistów i personelu ds. Kontroli jakości, więc ogólnie nasze kierownictwo wydawało się, że to dobry zakup.

Mając to doświadczenie, dość przychylnie patrzę na analizę kodu statycznego.

Zaczynając od nowego języka, miło jest mieć trenera. Tak myślę o narzędziach do analizy statycznej. Piszę dużo javascript i na początku nauczyłem się kilku złych nawyków, głównie dlatego, że przenosiłem niektóre rzeczy z wcześniejszych języków. JavaScript jest dość elastyczny, więc możesz uciec od praktycznie wszystkiego, ale gdybym ostrzegał jslinta o pewnych wzorach, od samego początku wybrałbym lepsze wzorce kodowania, zamiast konieczności ponownego uczenia się różnych rzeczy.

Analizatory statyczne są w zasadzie przeglądami kodów wspomaganymi maszynowo. Wskażą wątpliwe obszary, które mogą zostać pominięte podczas regularnych testów.

Na przykład, czy autor naprawdę chciał wykonać zadanie w tym warunku?

if (x = 1) {
    ...
}

A może nowicjusz myli casting leksykalny:

char* number = "123";
int converted = number;

Z pewnością statyczne analizatory wymagają modyfikacji. Z drugiej strony kontrola wersji, strony wiki, narzędzia do śledzenia błędów, ładne drukarki i inne narzędzia również wymagają pewnej konfiguracji. Im większy projekt, tym lepsza nagroda za pierwszą pracę.

Z punktu widzenia konsultanta każde narzędzie do analizy statycznej będzie generować hałas, ale nie wszystkie analizatory statyczne są sobie równe. Narzędzia do analizy statycznej, takie jak Coverity, Klocwork, Grammatech, mają dobre techniki analizy, które powinny dawać dokładniejsze wyniki. Jeśli dostroisz i poprawisz trochę więcej, zazwyczaj uzyskasz lepsze wyniki (w końcu analizatory statyczne muszą być zdolne do działania na wszystkich różnych typach kodu, od małego urządzenia medycznego do sieciowego systemu operacyjnego). Zdefiniowanie „hałasu” zależy również od kryteriów, które stanowią raport, który można naprawić. Na jednym końcu spektrum niektórzy programiści zaznaczają wszystkie raporty, których nie naprawiają, jako „fałszywe” (nawet źle napisany kod, którego nie mają czasu na naprawienie), a na drugim końcu,

Niektóre z tych narzędzi są bardziej skoncentrowane na analizie, a inne bardziej na komputerze - chociaż wszystkie trzy mają funkcje, które obsługują oba z nich. Jak wspomniano @Bob, kosztują pieniądze.

W mojej poprzedniej firmie korzystaliśmy z analizatora statycznego Parasoft. Zespół wierzył, że co najmniej 60% błędów w czasie wykonywania zostało wykrytych przed kompilacją.

Analizę statyczną można również przeprowadzić bez narzędzi, wykonując ręczne przeglądy kodu oprogramowania. Jest to często najbardziej opłacalny sposób na poprawę jakości kodu.

Drugą najlepszą opcją jest inwestowanie w jedno lub więcej wysokiej klasy narzędzi do analizy statycznej (takich jak wcześniej wspomniany Coverity lub KLOCwork). Ponieważ narzędzia te wykonują na przykład znacznie głębsze analizy niż strzępki, stosunek sygnału do szumu jest znacznie lepszy.

Rozważam użycie kłaczków jako trzeciej opcji ze względu na wysoki poziom hałasu. Zastosowanie kłaczków do istniejącego projektu może być zniechęcającym zadaniem.

Ogólnie rzecz biorąc, statyczna analiza programu znacznie się rozwinęła w ostatnich latach. Obecne narzędzia do analizy statycznej są w stanie przeprowadzać głębokie analizy międzyproceduralne i mogą automatycznie identyfikować na przykład warunki przed i po zabiegu. Może to być również bardzo pomocne w późniejszych recenzjach kodu.

Ze względu na wysoki współczynnik fałszywych wyników dodatnich nie należy używać narzędzia analizy statycznej (takiego jak lint lub FindBugs) dla każdej kompilacji.

Raczej jest to dobry test rozsądku, aby skonsultować się, gdy masz błąd i nie możesz go rozgryźć . W takim przypadku możesz wywołać fałszywe alarmy i być może zawęziłeś już możliwe źródła błędu. Na przykład, jeśli odtworzysz swój błąd, nawet nie wykonując żadnego modułu, możesz zignorować to, co dla nich mówi FindBugs. Jest to szczególnie pomocne, gdy patrzysz na fragment kodu i myślisz, że mówi on jedną rzecz, podczas gdy kompilator czyta go dosłownie (na przykład w Javie, gdy masz equalsmetodę, która przyjmuje typ klasy zamiast Object).

Możesz także włączyć narzędzia do analizy statycznej jako część procesu programowania: gdy programista otrzyma przegląd kodu, powinien również uruchomić na nim FindBugs. Krótko mówiąc, jest to przydatne, ale nie będziesz go używać tak często, jak kompilator lub edytor tekstu.