Мне никогда не нравилась метрика цикломатической сложности (cyclomatic complexity), которую большинство инструментов использует для анализа сложности кода. Просто она задумана скорее для того, чтобы показать вариативность сценариев в коде, что, естественно, влияет на его сложность, но не всегда прямолинейно. Посыл идет скорее к сложности тестирования, чтобы убедиться что код работает правильно. В случае автоматизации тестирования, цикломатическая сложность говорит нам сколько тестов нужно написать на этот код. В случае ручного тестирования – сколько должно быть разных сценариев для этого кода (тут на деле еще сложнее, потому что не до каждого такого сценария может добраться легко ручное тестирование).
Получается, что это всего лишь одна из граней сложности кода. И можно легко написать код, который будет не так сильно витьеватым с точки зрения логики переходов, но зато абсолютно непонятным и сложным для восприятия за счет корявого структурирования и не очень хорошего именования методов, переменных, параметров. А еще есть код, который реализует “value matching” с помощью нескольких swich/case или if/else if выражений. Такой код, будучи хорошо отформатированным, читается очень легко и с трудом может быть назван сложным. Поэтому подобные примеры многие разработчики руками помечают в инструментах для статического анализа как “won’t fix”.
На уровне класса цикломатическую сложность считают складыванием сложностей методов. И это снова таки приносит некоторую неразбериху. Может быть один класс с 5 методами, каждый из которых безумно просто, а другой класс будет содержать один метод, который имеет сложность 5. С точки зрения статического анализатора они будут одинаковые по сложности, хотя совершенно понятно что это не так. То есть, сравнивать большие классы по количеству методов с классами, имеющими сложные методы – не совсем корректно.
Есть некоторые другие метрики сложности кода, но их не так просто объяснить разработчикам, чтобы они использовали их в своей работе. Я очень рад, что в SonarQube обратили внимание на эту проблему и начали применять метрику когнитивной сложности параллельно с цикломатической. Она все еще не идеальна с точки зрения факторов, которые влияют на сложность кода, но куда лучше работает в перечисленных выше случаях.
В этой статье вы можете больше узнать о мотивации на конкретных примерах и разнице в получаемых значениях. Ну а попробовать метрику на практике достаточно легко, установив SonarQube 6.x. Всем здравых и полезных метрик!
Забавно считать что-то менее бесполезным чем X, если это что-то базируется на X, который просто домножен на коэффициент. Потом туда же намешана просто СУПЕР-МЕТРИКА сложности “количество линий кода” (в современном мире я надеюсь уже никто ничего этим не меряет) и добавлена щепотка комментариев, которые большинством считаются как анти-паттерн на внутреннем коде. И получилась конечно куда более полезная метрика. 😉
Менее бесполезная чем цикломатическая сложность. Комментарии в формуле опциональный аргумент(скорее неактуальный, надо обратить внимание на дату формализации этой формулы). И да, формула эмпирическая.
Вообще бесполезная метрика. Кто-то выдумал формулу странную. При чем тут комментарии к внутреннему коду?
Как по мне, неплохая метрика для метода http://www.projectcodemeter.com/cost_estimation/help/GL_maintainability.htm 🙂