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

Термін, який я бачу раз у раз, це "Цикломатична складність". Тут у SO я побачив декілька запитань про "як розрахувати CC мови X" або "Як мені зробити Y з мінімальною кількістю CC", але я не впевнений, що справді розумію, що це таке.

На веб-сайті NDepend я побачив пояснення, яке в основному говорить: "Кількість рішень у методі. Кожне, якщо, для, && і т. Д. Додає +1 до" оцінки "CC.) Це насправді? Якщо так, чому це погано? Я бачу, що можна захотіти тримати кількість if-тверджень досить низькою, щоб код був легким для розуміння, але чи справді це все для цього?

Або в цьому є якась глибша концепція?

Я не знаю глибшої концепції. Я вважаю, що це, як правило, розглядається в контексті індексу ремонтопридатності. Чим більше галузей існує в межах конкретного методу, тим складніше підтримувати розумову модель роботи цього методу (загалом).

Методи з вищою цикломатичною складністю також важче отримати повне охоплення коду в модульних тестах. (Дякую Марку W !)

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

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

Cyclocmatic complexity = Number of decision points + 1

Точками прийняття рішення можуть бути ваші умовні твердження, наприклад, якщо, якщо ... інакше, перемикач, для циклу, циклу while тощо.

Наступна таблиця описує тип програми.

• Цикломатична складність становить 1 - 10  Вважається звичайним застосуванням

• Цикломатична складність становить 11 - 20  Помірне застосування

• Цикломатична складність становить 21-50  Ризикове застосування

• Цикломатична складність становить понад 50  Нестабільне застосування

Вікіпедія може бути вашим другом у цьому: Визначення цикломатичної складності

В основному, ви повинні уявити свою програму як графік потоку управління, а потім

Складність (...) визначається як:

M = E − N + 2P

де

• M = цикломатична складність,
• E = кількість ребер графіка
• N = кількість вузлів графіка
• P = кількість підключених компонентів

CC - це концепція, яка намагається відобразити, наскільки складною є ваша програма і наскільки важко протестувати її в одному цілочисельному числі.

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

Ще один цікавий момент, який я чув:

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

Цикломатична складність - насправді просто моторошне модне слово. Насправді це міра складності коду, що використовується при розробці програмного забезпечення, щоб вказати на більш складні частини коду (з більшою ймовірністю помилка, і тому її потрібно ретельно і ретельно перевірити). Ви можете обчислити його за формулою E-N + 2P, але я б запропонував, щоб це автоматично розраховувалось плагіном. Я чув про емпіричне правило, згідно з яким ви повинні прагнути утримувати CC нижче 5, щоб забезпечити хорошу читабельність та ремонтопридатність вашого коду.

Нещодавно я експериментував з плагіном Eclipse Metrics на своїх проектах Java, і у нього є справді приємний і стислий файл довідки, який, звичайно, буде інтегрований із вашою регулярною довідкою Eclipse, і ви зможете прочитати ще деякі визначення різних мір складності та порад та підказок. щодо вдосконалення коду.

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

Кожна точка прийняття рішення у підпрограмі (цикл, перемикач, якщо тощо ...) по суті зводиться до еквівалента оператора if. Для кожного у ifвас є 2 кодових шляхи, які можна взяти. Отже, у 1-ї гілки є 2 шляхи коду, у другої - 4 можливі шляхи, у 3-ї - 8 і так далі. Існує щонайменше 2 ** N кодових шляхів, де N - кількість гілок.

Це ускладнює розуміння поведінки коду та тестування його, коли N перевищує деяке невелике число.

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

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

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

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

Це свого роду. Однак кожна гілка оператора "case" або "switch" має тенденцію рахуватися як 1. Фактично це означає, що CC ненавидить оператори case та будь-який код, який вимагає їх (командні процесори, автомати стану тощо).

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

Наприклад:

function F:
    if condition1:
       ...
    else:
       ...
    if condition2:
       ...
    else:
       ...

Графік управління потоком

Ви, мабуть, можете інтуїтивно зрозуміти, чому пов'язаний графік має цикломатичну складність 3.

Цикломатрична складність - це міра того, наскільки складною є одиниця програмного забезпечення. Вона вимірює кількість різних шляхів, якими може йти програма за допомогою умовних логічних конструкцій (If, while, for, switch & case і т. Д.). Якщо ви хочете дізнатись більше про його обчислення, ось чудове відео на YouTube, яке ви можете переглянути https://www.youtube.com/watch?v=PlCGomvu-NM

Це важливо при розробці тестових кейсів, оскільки воно розкриває різні шляхи або сценарії, якими може піти програма. "Щоб мати хорошу перевіряемость і ремонтопридатність, Маккейб рекомендує, щоб жоден програмний модуль не перевищував цикломатичної складності 10" (Marsic, 2012, с. 232).

Довідково: Марсіч., І. (2012, вересень). Розробка програмного забезпечення . Університет Рутгерса. Отримано з www.ece.rutgers.edu/~marsic/books/SE/book-SE_marsic.pdf