Zakresy złożoności cyklicznej [zamknięte]

Zamknięte . To pytanie jest oparte na opiniach . Obecnie nie przyjmuje odpowiedzi.

Chcesz poprawić to pytanie? Zaktualizuj pytanie, aby można było na nie odpowiedzieć faktami i cytatami, edytując ten post .

Zamknięte 5 lat temu .

Jakie są kategorie złożoności cyklicznej? Na przykład:

1-5: łatwe w utrzymaniu
6-10: trudne
11-15: bardzo trudne
20+: zbliża się niemożliwe

Od lat zakładam, że 10 to limit. A wszystko poza tym jest złe. Analizuję rozwiązanie i staram się ustalić jakość kodu. Z pewnością cykliczność nie jest jedynym pomiarem, ale może pomóc. Istnieją metody o cyklicznej złożoności 200+. Wiem, że to okropne, ale ciekawi mnie dolne zakresy, jak w moim przykładzie powyżej.

Znalazłem to :

Wyżej wymienione wartości odniesienia Carnegie Mellon określają cztery przybliżone zakresy wartości cykliczności złożoności:

metody od 1 do 10 są uważane za proste i łatwe do zrozumienia

wartości od 10 do 20 wskazują na bardziej złożony kod, który może być nadal zrozumiały; jednak testowanie staje się trudniejsze ze względu na większą liczbę możliwych gałęzi, które może przyjąć kod

wartości 20 i wyższe są typowe dla kodu z bardzo dużą liczbą potencjalnych ścieżek wykonania i można je w pełni uchwycić i przetestować z dużym trudem i wysiłkiem

metody idące jeszcze wyżej, np.> 50, są z pewnością nie do utrzymania

Podczas uruchamiania metryk kodu dla rozwiązania wyniki są zielone dla wszystkiego poniżej 25. Nie zgadzam się z tym, ale miałem nadzieję uzyskać inne dane wejściowe.

Czy istnieje ogólnie akceptowana lista zakresów złożoności cyklicznej?

design programming-practices metrics

— Bob Horn
źródło

Znalazłeś dane z Software Engineering Institute, organizacji uznanej za lidera w inżynierii oprogramowania. Nie rozumiem, jakie jest twoje pytanie - znalazłeś listę zakresów złożoności cyklicznej. Czego jeszcze szukasz?

— Thomas Owens

Widziałem różne zakresy; to był tylko jeden przykład. A MS pokazuje „zielony” dla wszystkiego poniżej 25. Zastanawiałem się, czy istnieje jedna zaakceptowana lista zakresów. Być może wtedy to znalazłem.

— Bob Horn

Zgadzam się z @ThomasOwens, ale cieszę się, że zadałeś to pytanie. Głosowałem za tym zarówno jako pytanie, jak i odpowiedź.

— Evorlor,

W drugim wydaniu Code Complete Steve'a McConnella zaleca on, aby cykliczna złożoność od 0 do 5 była zazwyczaj w porządku, ale powinieneś być świadomy, czy złożoność zaczyna się mieścić w zakresie od 6 do 10. Wyjaśnia ponadto, że cokolwiek powyżej złożoności 10, powinieneś zdecydowanie rozważyć refaktoryzację kodu.

— GibboK,

Odpowiedzi:

Przypuszczam, że zależy to od możliwości twojego personelu programistycznego, a w niemałej mierze od twojej wrażliwości jako menedżera.

Niektórzy programiści są zagorzałymi zwolennikami TDD i nie piszą żadnego kodu, nie pisząc najpierw testu jednostkowego. Inni programiści są w stanie doskonale tworzyć bezbłędne programy bez pisania pojedynczego testu jednostkowego. Poziom złożoności cyklicznej, który może tolerować każda grupa, prawie na pewno będzie się znacznie różnić.

To subiektywna miara; oceń ustawienie swojego rozwiązania Code Metrics i dostosuj go do najodpowiedniejszego miejsca, w którym czujesz się komfortowo, co daje sensowne wyniki.

— Robert Harvey
źródło

Uzgodnione, ponadto zależy to od tego, co jest przyczyną złożoności. Duże polecenie przełączające, które wywołuje inne funkcje, jako część automatu stanów lub czegoś podobnego, może mieć bardzo wysoką złożoność, chociaż być może jest praktycznie trywialne do zrozumienia.

— whatsisname

Czy deklaracje dużych zmian zazwyczaj nie wskazują na brak zasad OOP, takich jak polimorfizm? Maszyny stanowe mogą być implementowane w elegancki sposób, z OOP lub wzorami projektowymi. Nie?

— Bob Horn

W przypadku niektórych problemów przydatna jest „elegancja”, w przypadku innych sprawia, że wszystko staje się bardziej mylące. Nie ma srebrnej kuli.

— whatsisname

-1 Dla „Inni programiści są w stanie doskonale tworzyć bezbłędne programy bez pisania pojedynczego testu jednostkowego”. Nie możesz znać jego błędu, jeśli go nie przetestowałeś.

— Sebastien

@Sebastien: Brak testów jednostkowych nie oznacza, że nie został przetestowany. I tak, jeśli jesteś wystarczająco dobry, absolutnie możliwe jest napisanie kodu wolnego od błędów bez testów lub podstawowego testu dymu. Trzeba przyznać, że ci ludzie są rzadką rasą.

— Robert Harvey,

Nie ma predefiniowanych kategorii i kategoryzacja nie byłaby możliwa z kilku powodów:

Niektóre techniki refaktoryzacji przenoszą złożoność z jednego punktu do drugiego (nie z twojego kodu do frameworka lub dobrze przetestowanej biblioteki zewnętrznej, ale z jednej lokalizacji do innej bazy kodu). Pomaga zmniejszyć złożoność cykliczną i pomaga przekonać szefa (lub każdą osobę, która uwielbia prezentacje z ciągle rosnącą grafiką), że spędziłeś czas na tworzeniu czegoś wspaniałego, ale kod pozostaje tak zły, jak wcześniej.
Przeciwnie, czasami, kiedy refaktoryzujesz projekt przez zastosowanie pewnych wzorców projektowych i programistycznych, cykliczność złożoności może się pogorszyć, podczas gdy refaktoryzowany kod powinien być wyraźny: programiści znają wzorce programowania (przynajmniej powinni je znać), upraszcza to dla nich kod, ale złożoność cykliczna nie bierze tego pod uwagę.
Niektóre inne techniki bez refaktoryzacji w ogóle nie wpływają na złożoność cykliczną, jednocześnie znacznie zmniejszając złożoność kodu dla programistów. Przykłady: dodawanie odpowiednich komentarzy lub dokumentacji. „Modernizacja” kodu za pomocą cukru syntaktycznego.
Są po prostu przypadki, w których złożoność cykliczna jest nieistotna. Podoba mi się przykład podany przez whatsisname w jego komentarzu : niektóre duże switchinstrukcje mogą być bardzo jasne, a przepisanie ich w bardziej OOPy nie byłoby bardzo przydatne (i skomplikowałoby zrozumienie kodu przez początkujących). Jednocześnie te oświadczenia są katastrofą, cyklicznie złożonością.
Jak powiedział wcześniej Robert Harvey , zależy to od samego zespołu.

W praktyce widziałem kod źródłowy, który miał dobrą złożoność cykliczną, ale był okropny. Jednocześnie widziałem kod o dużej złożoności cyklicznej, ale nie miałem zbyt wiele bólu, rozumiejąc go.

Po prostu nie ma i nie może istnieć żadne narzędzie, które bezbłędnie wskazywałoby, jak dobry lub zły jest dany fragment kodu lub jak łatwo go utrzymać . Ponieważ nie można zaprogramować aplikacji, która powie, że dany obraz jest arcydziełem, a inny należy wyrzucić, ponieważ nie ma on wartości artystycznej.

Istnieją wskaźniki, które są podzielone według projektu (takie jak LOC lub liczba komentarzy na plik), i są wskaźniki, które mogą dać pewne surowe wskazówki (takie jak liczba błędów lub cykliczna złożoność). We wszystkich przypadkach są to tylko wskazówki i należy ich używać ostrożnie.

— Arseni Mourzenko
źródło

+1 Zgadzam się ze wszystkim, co zostało powiedziane. Cyklomatyczna złożoność lub LOC to tylko wskaźniki, które są przekazywane przez statyczną analizę kodu. Analizatory statyczne są świetnymi narzędziami, ale brakuje im zdrowego rozsądku. Wskaźniki te muszą być przetwarzane przez ludzki mózg, najlepiej należący do doświadczonego programisty. Tylko wtedy możesz stwierdzić, czy dane oprogramowanie jest niepotrzebnie złożone.