Вы считаете цикломатическую сложность полезной мерой?

Question

Я играл с измерением цикломатической сложности большой базы кода.

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

Результаты интересные, но не удивительные. То есть части, которые я знаю, были самыми волосатыми, были на самом деле самыми сложными (с рейтингом> 50). Но что я нахожу полезным, так это то, что каждому методу присваивается конкретный номер «плохости», на который я могу указать, когда решаю, с чего начать рефакторинг.

Вы используете цикломатическую сложность? Какой самый сложный фрагмент кода вы нашли?

Answer 1

Мы беспощадно проводим рефакторинг и используем цикломатическую сложность в качестве одного из показателей, определяющих код в нашем «списке попаданий». 1-6 мы не отмечаем сложность (хотя это может быть поставлено под сомнение по другим причинам), 7-9 сомнительна, и любой метод свыше 10 считается плохим, если не доказано иное.

Худшее, что мы видели, было 87 из чудовищной цепочки if-else-if в каком-то унаследованном коде, который нам пришлось взять на себя.

Answer 2

На самом деле цикломатическая сложность может быть использована за пределами порогового уровня метода. Для начала, один большой метод с высокой сложностью может быть разбит на несколько маленьких методов с меньшей сложностью. Но действительно ли это улучшило кодовую базу? Конечно, вы можете получить лучшую читаемость по всем этим именам методов. Но общая условная логика не изменилась. И общая условная логика часто может быть уменьшена путем замены условных выражений полиморфизмом .

Нам нужна метрика, которая не становится зеленой при простом разложении метода. Я называю это CC100 .

CC100 = 100 * (Общая цикломатическая сложность кодовой базы) / (Всего строк кода)

Answer 3

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

Я думаю, что простые метрики, такие как LOC, по крайней мере, так же хороши в большинстве случаев. Если функция не помещается на одном экране, почти не имеет значения, насколько она проста. Если функция принимает 20 параметров и создает 40 локальных переменных, не имеет значения, равна ли ее цикломатическая сложность 1.

Answer 4

Пока не найдется инструмент, который будет хорошо работать с шаблонами C ++ и методами метапрограммирования, в моей ситуации он мало поможет. В любом случае, просто помните, что

"не все вещи, которые считаются, могут быть размерен, и не все то, что может быть измеренным " Эйнштейн

Так что не забывайте передавать любую информацию этого типа и через человеческую фильтрацию.

Answer 5

Мы недавно начали его использовать. Мы используем NDepend для некоторого статического анализа кода, и он измеряет цикломатическую сложность. Я согласен, это достойный способ определения методов рефакторинга.

К сожалению, мы видели # выше 200 для некоторых методов, созданных нашими разработчиками в оффшорах.

Answer 6

Вы узнаете сложность, когда увидите ее. Основное, для чего полезен этот вид инструментов, - пометка частей кода, которые ускользнули от вашего внимания.

Answer 7

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

Однако я обнаружил, что когда я выполняю анализ цикломатической сложности кода других людей, он обычно вызывает чувство разочарования, беспокойства и общего гнева, когда я нахожу код с цикломатической сложностью в 100-х годах. Что заставляет людей писать методы, содержащие несколько тысяч строк кода?!

Answer 8

Это отлично подходит для помощи в определении кандидатов на рефакторинг, но важно держать свое мнение. Я бы поддержал диапазоны kenj0418 для подрезки направляющих.

Answer 9

Существует метрика Java под названием CRAP4J , которая эмпирически объединяет цикломатическую сложность и покрытие тестами JUnit для создания единой метрики. Он проводил исследования, чтобы попытаться улучшить свою эмпирическую формулу. Я не уверен, насколько это широко распространено.

Answer 10

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

Инструментарий необходим для эффективной обработки сложности кода. Инструмент NDepend для кода .NET позволит вам проанализировать многие аспекты сложности кода, включая такие метрики кода, как: Цикломатическая сложность, глубина вложения, отсутствие единства методов, охват тестами ...

включая анализ зависимостей и язык ( Code Query Language ), предназначенный для того, чтобы спросить, что сложного в моем коде, и написать правило?