{
    "codechecker.executor.runOnSave": true,
    "codechecker.executor.arguments": "--config ${workspaceFolder}/app/config/codechecker.yml --skip ${workspaceFolder}/app/config/skip.codechecker",
    "codechecker.backend.compilationDatabasePath": "${workspaceFolder}/build/compile_commands.json"
}

Po zastosowaniu tej konfiguracji w pliku .vscode/settings.json, CodeChecker będzie uruchamiany automatycznie za każdym razem, gdy zapiszesz plik. Jeśli masz również włączoną funkcję automatycznego zapisywania, analiza będzie odbywać się w tle podczas pisania, co usprawnia workflow.

Dla argumentów executora, możesz przekazać te same pliki, które są używane w CMake dla CodeCheckera. To zapewnia perfekcyjną synchronizację konfiguracji. Na koniec, pamiętaj, aby określić lokalizację bazy danych kompilacji, którą w naszym przypadku jest plik compile_commands.json.

Ciesz się płynnym procesem sprawdzania kodu!

Praktyczne Zastosowania

Pierwsza część artykułu skupiała się głównie na konfiguracji i wykorzystaniu CodeCheckera. W tej sekcji omówimy tematy mające praktyczne znaczenie w rzeczywistych projektach. Tematy te obejmują:

• Współpracę z zdalnym serwerem CodeChecker w środowisku Continuous Integration (CI),
• Integrację CodeCheckera z dowolnym narzędziem do sprawdzania przed-commit,
• Implementację funkcji automatycznego naprawiania,
• Uruchamianie CodeCheckera na projektach spoza ekosystemu Zephyr.

CodeChecker i CI

CodeChecker ma możliwość przesyłania swoich wyników na zdalny serwer. Ta sekcja skupia się na uruchomieniu lokalnego serwera w celu przesłania najnowszych wyników analizy. Dodatkowo, przedstawię rozszerzone funkcjonalności dostępne na serwerze w porównaniu do lokalnie generowanych raportów.

Na początek, uruchom serwer, wykonując następujące polecenie w osobnym terminalu:

CodeChecker server

Następnie sprawdź łączność, otwierając w przeglądarce adres:

http://localhost:8001/Default/

Jeśli wszystko działa poprawnie, ponownie uruchom analizę z dodatkową flagą, aby przekierować wyniki na serwer. Użyj poniższego polecenia:

west build -b qemu_cortex_m3 app --pristine -- -DZEPHYR_SCA_VARIANT=codechecker -DCODECHECKER_STORE_OPTS="--name;example;--url;localhost:8001/Default"

Po odświeżeniu przeglądarki zauważysz, że produkt "Default" zarejestrował nowy przebieg od ostatniej analizy. Przejdź do produktu "Default" > zakładka "Statistics", aby zobaczyć wykres ilustrujący naruszenia w czasie. Ilość dostarczonych informacji jest oczywiście ograniczona, mając tylko jedną iterację.

Z perspektywy serwera masz dostęp do tych samych statystyk co lokalnie. Jednak z pulpitami masz możliwość:

• Śledzenia zmian liczby naruszeń w czasie,
• Agregacji statystyk z wielu produktów w jednym miejscu,
• Klasyfikacji naruszeń jako "potwierdzone błędy", "fałszywe pozytywy" lub "celowe",
• Prowadzenia dyskusji na temat naruszeń, używając swojego osobistego konta.

Warto spróbować, zwłaszcza jeśli masz CodeCheckera skonfigurowanego w swoim projekcie. Uruchomienie i wdrożenie serwera jest stosunkowo proste.

Blokowanie commitów w przypadku nierozwiązanych naruszeń

W poprzedniej sekcji nauczyłeś się o różnych stanach, w jakich może znajdować się naruszenie. Te stany obejmują:

• Potwierdzony błąd
• Fałszywy pozytyw
• Celowy
• Nierozwiązany

Moim zdaniem, najgroźniejszym stanem jest nierozwiązany. Idealnie, takich problemów w ogóle nie powinno być. Dlaczego? Ponieważ co to oznacza? Czy ktoś jest świadomy istnienia takiego naruszenia? A może nie jest ono istotne? A może jest, i mamy do czynienia z poważnymi problemami. Wolę mieć jasność w tej kwestii. Dlatego cieszę się, że każde naruszenie może znaleźć się w jednym z tych stanów.

Jednak przejdźmy do sedna. Przypuszczalnie, chcesz sprawdzić, czy to w pre-commit hook czy na ciągłej integracji (CI), że nie ma nierozwiązanych naruszeń. Aby to osiągnąć, musisz przetworzyć wygenerowany raport używając polecenia podobnego do poniższego:

CodeChecker parse build/sca/codechecker/codechecker.plist --review-status unreviewed

To polecenie powinno zwrócić kod powrotu 2, co oznacza, że przynajmniej jeden raport został wygenerowany przez analizator. Kod powrotu inny niż 0 powinien być również zrozumiały dla każdego narzędzia pre-commit lub CI, co pozwala na użycie takiego polecenia do blokowania commitu lub builda CI. Jednak czy naprawdę chcemy przepchnąć ten kod z naruszeniami na główną gałąź? Naturalnie, takie sytuacje się zdarzą. Co wtedy? Cóż, zalecam oznaczenie tego naruszenia jako potwierdzonego w kodzie, abyś mógł się nim zająć, gdy nadejdzie właściwy czas. Można to zrobić, dodając komentarz podobny do poniższego:

// codechecker_confirmed [all] this code intentionally contains violations
while (1) blink_led();

Dzięki temu polecenie parsowania zakończy się sukcesem, a nadal będziesz mógł zobaczyć to naruszenie zarówno w swoim zintegrowanym środowisku programistycznym (IDE), jak i na zdalnym pulpicie. Czy to nie stwarza sytuacji korzystnej dla wszystkich?

Automatyczne Naprawianie

Style checkery często oferują opcję automatycznej korekty naruszeń. Tak jest również w naszym przypadku. Wymagane poprawki obejmują dodanie klamr po pętli while i zamianę 1 na true. Brzmi prosto, prawda? Oczywiście. Wykorzystanie CodeCheckera może załatwić tę sprawę bez wysiłku. Wystarczy wykonać poniższe polecenie, a wszystkie poprawki zostaną naniesione, zostawiając CodeCheckera zadowolonego:

CodeChecker fixit build/sca/codechecker/codechecker.plist --apply

CodeChecker w Projekcie Bez Zephyra

Wow, wszystko brzmi imponująco do tej pory, ale co, jeśli nie pracujesz nad projektem Zephyra? Nie martw się, nie jesteś zagubiony! Bardzo przydatną funkcją jest możliwość szybkiej analizy w CodeCheckerze. Jak to działa? Analizuje on trwający proces budowy lub bazę danych kompilacji, aby przeprowadzić analizę na podstawie tych informacji. Zanurzmy się w to!

#include <chrono>
#include <iostream>
#include <thread>
namespace {
    const auto BLINK_DURATION = std::chrono::milliseconds(1000);
    void blink_led() {
        std::cout << "LED blinks" << std::endl;
        std::this_thread::sleep_for(BLINK_DURATION);
    }
}
int main(void)
{
    while (1) blink_led();
    return 0;
}

blink: main.cpp
	g++ -Wall main.cpp -o blink

CodeChecker check --config ../app/config/codechecker.yml --build "make"

> CodeChecker check --config ../app/config/codechecker.yml --build "make"
...
[INFO 2024-07-09 09:34] - ----=================----
[INFO 2024-07-09 09:34] - Analysis length: 0.8173582553863525 sec.
[STYLE] /repos/code-checker-example/non-zephyr-app/main.cpp:17:12: implicit conversion 'int' -> bool [readability-implicit-bool-conversion]
    while (1) blink_led();
           ^
[STYLE] /repos/code-checker-example/non-zephyr-app/main.cpp:17:14: statement should be inside braces [readability-braces-around-statements]
    while (1) blink_led();
             ^
Found 2 defect(s) in main.cpp
...