Що означає «цикломатична складність» мого коду?

Я новачок у статичному аналізі коду. Моя заявка має складність у цикломатиці 17 754. У самій програмі всього 37 672 рядки коду. Чи справедливо сказати, що складність висока на основі рядків коду? Що саме говорить мені цикломатична складність?

Що саме говорить мені цикломатична складність?

Цикломатична складність - це не міра рядків коду, а кількість незалежних шляхів через модуль. Ваша цикломатична складність 17 754 означає, що ваша програма має 17 754 унікальних шляхів через неї. Це має кілька наслідків, як правило, з точки зору того, як важко зрозуміти та протестувати свою заявку. Наприклад, цикломатична складність - це кількість тестових випадків, необхідних для досягнення 100% охоплення галузями, припускаючи добре написані тести.

Гарною відправною точкою може стати стаття Вікіпедії про цикломатичну складність . У ньому є кілька фрагментів псевдокоду та кілька графіків, які показують, у чому полягає цикломатична складність. Якщо ви хочете дізнатися більше, ви також можете прочитати документ МакКейба, де він визначав цикломатичну складність .

У моїй заявці є цикломатична складність 17 754 рядків коду. У самій програмі всього 37 672 рядки коду. Чи справедливо сказати, що складність висока на основі рядків коду?

Зовсім ні. Додаток з кількома рядками коду та великою кількістю умовних умов, що вкладаються в цикли, може мати надзвичайно високу цикломатичну складність. З іншого боку, додаток з невеликими умовами може мати низьку циклічну складність. Це занадто спрощує це, але я думаю, що це ідея впоперек.

Не знаючи більше про те, що робить ваша програма, можливо, нормально мати більш високу цикломатичну складність. Я б запропонував виміряти цикломатичну складність на рівні класу чи методу, однак замість просто рівня застосування. Це трохи керованіше, концептуально, я думаю - простіше візуалізувати або концептуалізувати шляхи методом, ніж шляхи через велику програму.

Цикломатична складність - це спосіб визначити, чи потрібно реконструювати ваш код. Код аналізується і визначається число складності. Складність визначається шляхом розгалуження (якщо заяви тощо). Складність також може враховувати введення циклів тощо та інші фактори залежно від використовуваного алгоритму.

Число корисне на рівні методу. На більш високих рівнях це просто число.

Число 17754 вказує на складність проекту (загальний код), що не має такого великого значення.

Поглинання рівня складності на рівні класу та методу визначає області коду, які потрібно переробити на більш дрібні методи або переробити для усунення складності.

Розглянемо CASEтвердження з 50 випадків одним методом. Можливо, кожна держава має різну логіку бізнесу. Це спричинить циклічну складність 50. Є 50 пунктів прийняття рішень. Оператор CASE, можливо, доведеться переробити за допомогою заводського зразка, щоб позбутися логіки розгалуження. Іноді ви можете зробити рефактор (розбити метод на більш дрібні частини), а в деяких випадках лише редизайн зменшить складність.

Загалом для рівня складності методу:

• <10 Легкий в обслуговуванні
• 11-20 Важче у обслуговуванні
• 21+ Кандидати на рефакторинг / редизайн

Також врахуйте, що більш високі складності ускладнюють код тестування.

Найвища складність, яку я бачив в одному методі, становила 560. Це було приблизно 2000 рядків операторів if, якщо один метод. В основному нездійсненний, незаперечний, повний потенційних помилок. Уявіть усі одиничні тестові випадки, необхідні для цієї логіки розгалуження! Не добре.

Спробуйте втримати всі методи, які не досягли 20 років, і зрозумійте, що коштує переробляти будь-який метод, щоб зробити його менш складним.

Це кількість різних шляхів у вашій програмі. Перегляньте цю статтю IBM про CC .

Це здається високим, але у вашому випадку це додавання CC всіх ваших методів усіх ваших класів та методів. Мої приклади дуже розтягнуті, оскільки я не знаю, як структурований ваш код, але ви також можете мати один метод монстра з 37672 рядками коду або 3767 методами з приблизно 10 рядками коду. Що я маю на увазі, що на рівні програми цей показник не означає дуже багато, але на рівні методу він може допомогти вам оптимізувати / переписати свій код на більш дрібні методи, щоб вони були менш схильні до помилок.

Що я особисто читав багато разів, це те, що методи з КК вище 10 мають більш високий ризик дефектів.

Я використовую Sonar для тестування якості коду моїх програм, і, за замовчуванням, я думаю, це викликає попередження, якщо у вас є методи з +10 CC. Але це може нічого не означати. Один конкретний приклад: якщо ви використовуєте Eclipse для створення equalsметоду, заснованого на властивостях вашої фасолі, CC дуже швидко перейде над дахом ...

Це залежно від того, яким інструментом ви користувалися. Деякі інструменти з відкритим кодом там приймають клас як модуль або інший рівень структури як модуль. Отже, чим більший проект отримує, тим більша цикломатична складність має. Однак, на моє особисте розуміння, це має бути на основі функцій. Оскільки більший проект отримує, тим функцій він відвідує.

Я рекомендую вам скористатися інструментом під назвою Lizard, і ви можете знайти код ресурсу та завантажити zip-файл на github. Він також має Інтернет-версію, якщо у вашому коді не так багато конфіденційної інформації.

Змістовна CCN, про яку ви повинні дбати, знаходиться на основі функцій, відмінних від будь-яких інших. Крім того, зберегти CCN unber 15 кожної функції було б ідеальним діапазоном.