Metryki kodu — złożoność cyklatyczna

Podczas pracy z metrykami kodu jeden z najmniej zrozumiałych elementów wydaje się być złożonością cyklatyczną. Zasadniczo ze złożonością cyklatyczną większa liczba jest zła, a niższe liczby są dobre. Można użyć złożoności cyklomatycznej, aby zrozumieć, jak trudne może być przetestowanie, utrzymanie lub rozwiązywanie problemów z danym kodem, a także wskazać, jak prawdopodobne jest, że kod będzie powodował błędy. Na wysokim poziomie określamy wartość złożoności cyklatycznej, zliczając liczbę decyzji podjętych w kodzie źródłowym. W tym artykule zaczniesz od prostego przykładu złożoności cyklatycznej, aby szybko zrozumieć koncepcję, a następnie przyjrzeć się dodatkowym informacjom na temat rzeczywistego użycia i sugerowanych limitów. Na koniec znajduje się sekcja cytatów, która może służyć do dokładniejszego zagłębiania się w ten temat.

Przykład

Złożoność cyklatyczna jest definiowana jako pomiar "ilości logiki decyzyjnej w funkcji kodu źródłowego" NIST235. Mówiąc mówiąc, tym więcej decyzji, które należy podjąć w kodzie, tym bardziej złożone jest.

Zobaczmy to w akcji. Utwórz nową aplikację konsolową i natychmiast oblicz metryki kodu, przechodząc do Analizowanie > Obliczanie Metryk Kodu dla Rozwiązania.

Zwróć uwagę, że złożoność cyklatyczna wynosi 2 (najniższa możliwa wartość). Jeśli dodasz kod niepodejmowania decyzji, zwróć uwagę, że złożoność nie zmienia się:

Jeśli dodasz decyzję, wartość złożoności cyklatycznej wzrośnie o jedną:

Po zmianie instrukcji if na instrukcję switch z czterema decyzjami do podjęcia, liczba decyzji wzrasta z dwóch do sześciu.

Przyjrzyjmy się (hipotetycznej) większej bazie kodu.

Zwróć uwagę, że większość elementów, podczas zagłębiania się w szczegóły w klasie Products_Related, ma wartość równą jeden, ale kilka z nich ma złożoność równą pięciu. Sama różnica może nie być duża, ale biorąc pod uwagę, że większość innych członków ma jeden w tej samej klasie, na pewno należy przyjrzeć się bliżej tym dwóm elementom i zobaczyć, co jest w nich. Możesz dokładniej przyjrzeć się, klikając prawym przyciskiem myszy element i wybierając Przejdź do kodu źródłowego z menu kontekstowego. Przyjrzyj się bliżej Product.set(Product):

Biorąc pod uwagę wszystkie instrukcje if, można zrozumieć, dlaczego złożoność cyklomatyczna wynosi pięć. W tym momencie możesz zdecydować, że ten wynik jest akceptowalnym poziomem złożoności lub można refaktoryzować, aby zmniejszyć złożoność.

Liczba magiczna

Podobnie jak w przypadku wielu metryk w tej branży, nie ma dokładnego limitu złożoności cyklatycznej, który pasuje do wszystkich organizacji. Jednak NIST235 wskazuje, że limit 10 jest dobrym punktem wyjścia:

"Dokładna liczba, która ma być używana jako limit, pozostaje jednak nieco kontrowersyjna. Oryginalny limit 10 zgodnie z propozycją McCabe ma znaczące dowody pomocnicze, ale limity tak wysokie jak 15 zostały wykorzystane pomyślnie. Limity powyżej 10 powinny być zarezerwowane dla projektów, które mają kilka zalet operacyjnych w przypadku typowych projektów, na przykład doświadczonych pracowników, projektu formalnego, nowoczesnego języka programowania, programowania strukturalnego, przewodników kodu i kompleksowego planu testowego. Innymi słowy, organizacja może wybrać limit złożoności większy niż 10, ale tylko wtedy, gdy na pewno wie, co robi i jest gotów poświęcić dodatkowy wysiłek testowy wymagany przez bardziej złożone moduły." NIST235

Złożoność cyklatyczna i numery wierszy

Samo spojrzenie na liczbę wierszy kodu jest w najlepszym razie bardzo szerokim predyktorem jakości kodu. Istnieje pewna podstawowa prawda, że tym więcej wierszy kodu w funkcji, tym bardziej prawdopodobne jest, że występują błędy. Jednak po połączeniu złożoności cyklatycznej z wierszami kodu masz znacznie jaśniejszy obraz potencjalnego błędu.

Zgodnie z opisem w Centrum Technologii Software Assurance (SATC) w NASA:

"SATC stwierdził, że najbardziej efektywna ocena jest kombinacją wielkości i (cyklotycznej) złożoności. Moduły o dużej złożoności i dużym rozmiarze mają zwykle najniższą niezawodność. Moduły o niskim rozmiarze i wysokiej złożoności są również ryzykiem niezawodności, ponieważ zwykle są bardzo terse code, co jest trudne do zmiany lub modyfikacji." SATC

Analiza kodu

Analiza kodu obejmuje kategorię reguł konserwacji. Aby uzyskać więcej informacji, zobacz Reguły konserwacji. W przypadku korzystania ze starszej analizy kodu zestaw reguł rozszerzonych wytycznych dotyczących projektowania zawiera obszar możliwości konserwacji:

W obszarze utrzymywalności istnieje reguła dotycząca złożoności:

Ta reguła generuje ostrzeżenie, gdy złożoność cyklatyczna osiągnie 25, dzięki czemu może pomóc uniknąć nadmiernej złożoności. Aby dowiedzieć się więcej na temat reguły, zobacz CA1502

Łączenie tego wszystkiego

Najważniejsze jest to, że duża liczba złożoności oznacza większe prawdopodobieństwo błędów ze zwiększonym czasem utrzymania i rozwiązywania problemów. Przyjrzyj się bliżej wszelkim funkcjom, które mają wysoką złożoność i zdecyduj, czy powinny być refaktoryzowane, aby uczynić je mniej złożonymi.

Cytatów

MCCABE5

McCabe, T. i A. Watson (1994), Software Complexity (CrossTalk: The Journal of Defense Software Engineering).

NIST235

Watson, A. H., & McCabe, T. J. (1996). Testowanie strukturalne: metodologia testowania przy użyciu metryki złożoności cyklatycznej (specjalna publikacja NIST 500-235). Pobrano 14 maja 2011 r. z witryny internetowej McCabe Software: http://www.mccabe.com/pdf/mccabe-nist235r.pdf

SATC

Rosenberg, L., Hammer, T., Shaw, J. (1998). Metryki i niezawodność oprogramowania (Postępowanie na międzynarodowym sympozjum IEEE na temat inżynierii niezawodności oprogramowania). Pobrano 14 maja 2011 r. z witryny internetowej Penn State University: https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159