Вопрос

Термин, который я время от времени встречаю, - это "Цикломатическая сложность".Здесь, на SO, я видел несколько вопросов о "как вычислить CC языка X" или "Как мне выполнить Y с минимальным количеством CC", но я не уверен, что действительно понимаю, что это такое.

На Веб - сайт NDepend, Я видел объяснение, которое в основном гласит "Количество решений в методе.Каждое if, for, && и т.д.добавляет +1 к CC "оценка").Это действительно так?Если да, то почему это плохо?Я вижу, что можно было бы захотеть сохранить количество операторов if на достаточно низком уровне, чтобы код был легким для понимания, но действительно ли это все?

Или в этом есть какая-то более глубокая концепция?

Это было полезно?

Решение

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

Методам с более высокой цикломатической сложностью также сложнее получить полное покрытие кода в модульных тестах.(Спасибо Отметка W!)

Это, конечно, включает в себя все остальные аспекты ремонтопригодности.Вероятность ошибок / регрессий / так далее.Однако основная концепция довольно прямолинейна.

Другие советы

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

Cyclocmatic complexity = Number of decision points + 1

Точками принятия решения могут быть ваши условные операторы, такие как if, if ... else, switch , цикл for, цикл while и т.д.

Следующая диаграмма описывает тип приложения.

  • Цикломатическая сложность лежит в пределах 1-10 , чтобы считаться нормальной приложение

  • Цикломатическая сложность составляет 11-20  Умеренное применение

  • Цикломатическая сложность составляет 21 – 50  Рискованное применение

  • Цикломатическая сложность составляет более 50  Нестабильное приложение

Википедия может быть вашим другом в этом вопросе: Определение цикломатической сложности

По сути, вы должны представить свою программу как график потока управления и тогда

Сложность (...) определяется как:

M = E − N + 2P

где

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

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

Да, это действительно так.Чем больше путей выполнения может занять ваш код, тем больше вещей необходимо протестировать и тем выше вероятность ошибки.

Еще один интересный момент, который я услышал:

Места в вашем коде с самыми большими отступами должны иметь самый высокий CC.Как правило, это наиболее важные области для обеспечения охвата тестированием, поскольку ожидается, что их будет сложнее читать / поддерживать.Как отмечается в других ответах, это также более сложные области кода для обеспечения покрытия.

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

Я совсем недавно экспериментировал с Плагин Метрики Затмение в моих проектах Java, и в нем есть действительно хороший и краткий файл справки, который, конечно же, интегрируется с вашей обычной справкой Eclipse, и вы можете прочитать еще несколько определений различных показателей сложности, а также советы и хитрости по улучшению вашего кода.

Вот и все, идея заключается в том, что метод с низким CC имеет меньше развилок, зацикливаний и т.д., Которые все делают метод более сложным.Представьте, что вы просматриваете 500 000 строк кода с помощью анализатора и видите пару методов, которые имеют одер на порядок выше CC.Это позволяет вам затем сосредоточиться на рефакторинге этих методов для лучшего понимания (также часто бывает, что высокая CC имеет высокий процент ошибок).

Каждая точка принятия решения в подпрограмме (цикл, переключение, if и т.д.) по существу сводится к эквиваленту оператора if.Для каждого if у вас есть 2 кодовых пути, которые можно использовать.Таким образом, в 1-й ветви есть 2 пути к коду, во второй - 4 возможных пути, в 3-й - 8 и так далее.Существует по крайней мере 2 **N кодовых путей, где N - количество ветвей.

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

В представленных до сих пор ответах не упоминается корреляция качества программного обеспечения с цикломатической сложностью.Исследования показали, что наличие более низкого показателя цикломатической сложности должно помочь в разработке программного обеспечения более высокого качества.Это может помочь с такими качественными атрибутами программного обеспечения, как читаемость, ремонтопригодность и переносимость.В общем случае следует попытаться получить цикломатическую метрику сложности в пределах 5-10.

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

Цикломатическая сложность вычисляется с использованием графика потока управления.Количество количественных показателей линейно независимых путей в исходном коде программы называется цикломатической сложностью ( if/ if else / for / while ) .

Цикломатрическая сложность - это, по сути, показатель для определения областей кода, которым требуется больше внимания для удобства сопровождения.По сути, это был бы вклад в рефакторинг.Это определенно указывает на область улучшения кода с точки зрения избежания глубокого вложенного цикла, условий и т.д.

В некотором роде это так.Однако каждая ветвь инструкции "case" или "switch", как правило, считается равной 1.По сути, это означает CC ненавидит операторы case и любой код, который их требует (командные процессоры, конечные машины и т.д.).

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

Например:

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

Control Flow Graph

График потока управления

Вероятно, вы можете интуитивно понять, почему связанный граф имеет цикломатическую сложность, равную 3.

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

Это важно при разработке тестовых примеров , поскольку оно раскрывает различные пути или сценарии , которые может использовать программа ."Для обеспечения хорошей тестируемости и ремонтопригодности Маккейб рекомендует ни один программный модуль не должен превышать цикломатическую сложность 10" (Марсик, 2012, с.232).

Ссылка:Марсич., И.(2012, сентябрь). Разработка программного обеспечения.Университет Ратгерса.Извлечено из www.ece.rutgers.edu /~marsic/books/SE/книга-SE_marsic.pdf

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top