Názory k článku Použití nástroje Radon pro zjištění cyklomatické složitosti zdrojových kódů
-
YC (neregistrovaný)
Nápad měřit složitost kódu je podle mě dobrý. O implementaci se to ale říct nedá. Autoři to vyloženě odflákli. To co zvyšuje složitost reálně je spíš těsná provázanost více složitých bloků kódu, než to, že mi přibydou dva ify na kontrolu vstupních parametrů.
Kromě toho je to další z metrik razících přístup "pište krátké funkce". (když rozdělíte jednu funkci na dvě, klesne cyklometrická složitost na polovinu ;-) ) Jenže funkce má být prostě tak dlouhá, jak je potřeba, a násilně ji rozdělovat jen proto, aby byla rozdělená, je pitomost.Krom toho už vidím, jak se toho chytí nějaká banda fanatiků a budou tlačit na svoje programátory, ať mají tohle číslo co nejmenš.
-
atarist (neregistrovaný)
jenze pokud budes mit funkce se slozitosti treba 30, tak evidentne v te funkci delas vic nez jednu jedinou operaci a skutecne je na miste refaktoring. Nebo jinak - chtel bych skutecne videt funkci, ktera ma cyklomatickou slozitost >30 a dela jen jednu operaci a da se dobre otestovat a pochopit.
-
Pavel TišnovskýZlatý podporovatelJá to při zkracování špatně napsal, omlouvám se. Mělo být "% komentářů ve zdrojovém kódu převedené na radiány".
V článku jsem to opravil, díky za upozornění.Ten výpočet je takový prapodivný, protože napřed si vypočítají to %, ale proč se to převádí na radiány, tu teorii za tím netuším :-):
comments_lines = raw.comments + (raw.multi if count_multi else 0)
comments = comments_lines / float(raw.sloc) * 100 if raw.sloc != 0 else 0
...
...
...
comments_scale = math.sqrt(2.46 * math.radians(comments)) -
Honza (neregistrovaný)
Nejde o přepočet na radiány. Jde o vážený součet 4 metrik. Prostě usoudili, že pro udržovatelnost jsou ty metriky důležité právě v tomto poměru:
The Software Maintainability Index (MI) is a single-value indicator for the maintainability of a software system. It was proposed by Oman and Hagemeister in the early nineties [1]. The Maintainability Index is computed by combining four traditional metrics. It is a weighted composition of the average Halstead Volume per module, the Cyclomatic Complexity, the number of lines of code (LOC) and the comment ratio of the system.
-
v (neregistrovaný)
na jakém intervalu? :))
podle kódu, který uvedl Tišnovský je to 0 až 100 a vypadá to takhle http://www.wolframalpha.com/input/?i=sin+(sqrt+(+2.46+*+x+)+)+for+x+from+0+to+100 (a asi by to tak byl bug)
tady jsem našel to metriku, asi to má omezit vliv pom+ru komentářů na výsledek
http://static1.1.sqspcdn.com/static/f/702523/9457031/1290003349713/200108-Welker.pdf?token=7+6uapX6Nng92A2i5ggANrgiH34=jinak, zabývám se tím z čiré zvědavosti
-
Karel (neregistrovaný)
C je číslo od 0 až 100 a tvrdí se o tom, že jsou to úhlové stupně. Převede se to na radiány, takže máte číslo od 0 do 1.745. To se vynásobí číslem 2.46, takže máte číslo od 0 do 4.29. No a nakonec odmocnina, takže čísla od 0 do 2.072. Zapsáno jinak je to od 0 do 0.66 Pi.
Pokud tohle někdo prožene sinem, a čím vyšší číslo, tím lépe, pak to začne na nule a rychle roste. Kolem cca 60% procent komentářů to dosáhne maxima, začne to klesat a při 100% komentářů se to zastaví na 0.87, což je stejná hodnota, jakou to mělo u cca 27% komentářů.
http://www.wolframalpha.com/input/?i=sin+(+sqrt+(+2.46+*+(x*Pi%2F180)+))+for+x+from+0+to+100
Osobně mi to přijde, že někdo hledal funkci, která do nějaké hodnoty roste a pak zase klesá. Nic víc bych za tím nehledal a v konstantě 2.46 bych viděl spíše nastřelenou hodnotu, se kterou to vypadá dobře, než nějaký produkt výzkumu a výsledek analýzy milionů řádků kódu.
-
misaz (neregistrovaný)
Ty metriky jsou jenom orientační. Jde napsat perfektně hodnocenou prasárnu a stejně tak to za jistých okolností dokáže v podstatě bezproblémový kód ohodnotit jako katastrofu.
Já to používám (v jiném programovacím jazyku, ale to je jedno), abych si třídy setřídil třídy od nejhorší po nejlepší, obvykle mi to ukáže, to co sám tuším a když mám chvíli čas, tak začínám s přepisem špatných souborů/tříd.
-
Pavel TišnovskýZlatý podporovatel
My to používáme, tedy spíš cyklomatickou složitost, protože ta je dobře pochopitelná (u MI většinou není jasné, co a jak zlepšit). Ukazuje se, že ten nejhorší kód, kód s nejmenším pokrytím unit testy a kód s největší chybovostí, má v naprosté většině případů kategorii cykl. složitosti od D výš. Samozřejmě je možné botu udělat i v jednodušších funkcích, ale tam je většinou pokrytí testy na takové úrovni, že se to zachytí (o tom, proč nemáme lepší pokrytí unit testy se raději pobavím někde u piva :-).
https://fabric8-analytics.github.io/dashboard/dashboard.html
-
a (neregistrovaný)
Pro detekci prilis slozitych casti kodu bohate staci flake8 s pluginem mccabe, pouzivam max-complexity = 10.
Radon pouzivam spis jen pri prvotnim pruzkumu neznameho kodu - zmerim si velikost v SLOC a necham si ukazat nejslozitejsi casti. Pokud je to kod ktery aktivne udrzuju, staci mi spravne nastaveny flake8. Prilis slozite casti kodu se oznaci pomoci # noqa: C901 a do backlogu se prida ticket na refactoring dane casti.
ČLÁNKY DO MAILU