Цикломатичні діапазони складності [закрито]

Які категорії цикломатичної складності? Наприклад:

1-5: простий у обслуговуванні
6-10: важко
11-15: дуже важко
20+: наближення неможливо

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

Я знайшов це :

Вищезазначені референтні значення Карнегі Меллона визначають чотири приблизні діапазони для значень цикломатичної складності:

• методи від 1 до 10 вважаються простими та зрозумілими
• значення між 10 і 20 вказують на більш складний код, який все ще може бути зрозумілим; проте тестування стає складніше через більшу кількість можливих гілок, які може взяти код
• значення 20 і вище є типовими для коду з дуже великою кількістю потенційних шляхів виконання і їх можна повністю зрозуміти і протестувати лише з великими труднощами і зусиллями
• методи, що піднімаються навіть вище, наприклад> 50, безумовно, неможливо досягти

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

Чи існує загальновизнаний перелік діапазонів для цикломатичної складності?

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

Деякі програмісти є завзятими прихильниками TDD, і не будуть писати жодного коду, не спершу написавши одиничний тест. Інші програмісти цілком здатні створити ідеально хороші програми без помилок без написання єдиного тесту. Рівень цикломатичної складності, який кожна група може терпіти, майже напевно істотно відрізнятиметься.

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

Немає попередньо визначених категорій, і категоризація не буде можливою з кількох причин:

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

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

3. Деякі інші нерефакторні методи взагалі не впливають на цикломатичну складність, в той час як сильно знижують складність коду для розробників. Приклади: додавання відповідних коментарів або документації. "Модернізація" коду за допомогою синтаксичного цукру.

4. Існують просто випадки, коли цикломатична складність не має значення. Мені подобається приклад, наведений у його коментарі whatsisname : деякі великі switchвисловлювання можуть бути надзвичайно чіткими, і переписати їх більш доцільним способом OOPy було б не дуже корисно (і ускладнить розуміння коду початківцями). У той же час ці висловлювання є катастрофою, цикломатичною складністю.

5. Як уже говорив Роберт Харві вище , це залежить від самої команди.

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

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

Є метрики, які розбиті за дизайном (наприклад, LOC або кількість коментарів на файл), і є метрики, які можуть дати деякі непередбачені підказки (наприклад, кількість помилок або циклічна складність). У всіх випадках це лише підказки, і їх слід застосовувати обережно.