1. Strona główna
  2. Sylabus dla poziomu zaawansowanego – Techniczny analityk testowy (wersja z 19.10.2012)
  3. 5. Przeglądy
  4. 5.2 Korzystanie z list kontrolnych podczas przeglądów
  5. 5.2.2 Przeglądy kodu

5.2.2 Przeglądy kodu

Listy kontrolne przeglądów kodu są z założenia bardzo szczegółowe i, podobnie jak w przypadku przeglądów architektury, sprawdzają się najlepiej, jeśli dotyczą konkretnego języka programowania, projektu i przedsiębiorstwa. Uwzględnienie antywzorców dotyczących kodu może okazać się pomocne, szczególnie w przypadku mniej doświadczonych programistów.

Na listach kontrolnych używanych w trakcie przeglądów kodu można uwzględnić sześć poniższych elementów (propozycja na podstawie [Web-5]):

1. Struktura

  • Czy kod w pełny i prawidłowy sposób implementuje projekt?
  • Czy kod jest zgodny z odpowiednimi standardami kodowania?
  • Czy kod ma poprawną strukturę, jednolity styl i jednolite formatowanie?
  • Czy istnieją niewywoływane lub niepotrzebne procedury i inne fragmenty nieosiągalnego kodu?
  • Czy w kodzie pozostały zaślepki i procedury testowe?
  • Czy jakieś fragmenty kodu mogą zostać zastąpione wywołaniami do zewnętrznych komponentów wielokrotnego użytku lub funkcji z biblioteki?
  • Czy istnieją bloki powtarzającego się kodu, które można zastąpić pojedynczą procedurą?
  • Czy wykorzystanie pamięci jest efektywne?
  • Czy jako stałe używane są wartości symboliczne, a nie „magiczne liczby” lub stałe łańcuchowe?
  • Czy istnieją moduły o zbyt wysokim stopniu złożoności, które należy zrestrukturyzować lub podzielić na wiele modułów?

2. Dokumentacja

  • Czy kod jest udokumentowany w jasny i prawidłowy sposób, a styl komentarzy umożliwia proste wprowadzanie zmian?
  • Czy wszystkie komentarze mają treść zgodną z kodem?
  • Czy dokumentacja jest zgodna z obowiązującymi standardami?

3. Zmienne

  • Czy wszystkie zmienne są właściwie zdefiniowane i mają znaczące, spójne i zrozumiałe nazwy?
  • Czy istnieją zbyteczne lub nieużywane zmienne?

4. Operacje arytmetyczne

  • Czy w kodzie unika się porównywania liczb zmiennoprzecinkowych?
  • Czy w kodzie w systematyczny sposób unika się błędów zaokrągleń?
  • Czy w kodzie nie pojawiają się operacje dodawania i odejmowania liczb o różniących się znacznie rzędach wielkości?
  • Czy sprawdzane są dzielniki (czy są różne od zera i nie mają zaburzonych wartości)?

5. Pętle i gałęzie

  • Czy wszystkie pętle, gałęzie kodu i konstrukcje logiczne są pełne, poprawne i prawidłowo zagnieżdżone?
  • Czy w łańcuchach instrukcji IF-ELSEIF najczęstsze przypadki są sprawdzane na początku?
  • Czy w bloku instrukcji IF-ELSEIF lub CASE sprawdzane są wszystkie przypadki i czy są uwzględnione klauzule ELSE lub DEFAULT?
  • Czy każda instrukcja CASE ma klauzulę DEFAULT?
  • Czy warunki zakończenia pętli są oczywiste i zawsze osiągalne?
  • Czy indeksy (w tym indeksy tablic) są poprawnie zainicjowane tuż przed wejściem do pętli?
  • Czy niektóre z instrukcji znajdujących się w pętlach można umieścić poza pętlami?
  • Czy kod w pętli stara się nie manipulować zmienną sterującą ani korzystać z niej w momencie wyjścia z pętli?

6. Programowanie defensywne

  • Czy sprawdzane jest przekroczenie wartości granicznych w tablicy, rekordzie lub pliku przez indeksy, wskaźniki i indeksy tabel?
  • Czy sprawdzana jest poprawność i kompletność zaimportowanych danych i argumentów wejściowych?
  • Czy wszystkie zmienne wyjściowe mają przypisane wartości?
  • Czy w każdej instrukcji używany jest właściwy element danych?
  • Czy każdy przydział pamięci jest zwalniany?
  • Czy w przypadku dostępu do urządzeń zewnętrznych stosowane są limity czasu lub mechanizmy obsługi błędów?
  • Czy przed próbą dostępu do pliku kod sprawdza, czy plik istnieje?
  • Czy w momencie zakończenia programu wszystkie pliki i urządzenia pozostają w prawidłowym stanie?

Dalsze przykłady list kontrolnych używanych w przeglądach kodu na różnych poziomach testowania można znaleźć w serwisie [Web-6].