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

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

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

Я давно этим не пользовался, но в предыдущем проекте это действительно помогло выявить потенциальные проблемные места у кого-то код elses (конечно, не мой!)

Найдя область для проверки, я быстро обнаружил многочисленные проблемы (также много GOTOS, как вы поверите!) с логикой и некоторым действительно странным кодом WTF.

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

I frequently measure the cyclomatic complexity of my code. I've found it helps me spot areas of code that are doing too much. Having a tool point out the hot-spots in my code is much less time consuming than having to read through thousands of lines of code trying to figure out which methods are not following the SRP.

However, I've found that when I do a cyclomatic complexity analysis on other people's code it usually leads to feelings of frustration, angst, and general anger when I find code with cyclomatic complexity in the 100's. What compels people to write methods that have several thousand lines of code in them?!

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

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

«не все, что считается, может быть размерен, и не все то, что может быть измеренным " Эйнштейн

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

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

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

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

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

It's great for help identifying candidates for refactoring, but it's important to keep your judgment around. I'd support kenj0418's ranges for pruning guides.

+1 для значений списка совпадений kenj0418.

Худший, что я видел, был 275-й. Была пара других, более 200, которые мы смогли рефакторировать до гораздо меньших CC; они все еще были под кайфом, но это заставило их отодвинуть их еще дальше. Нам не повезло с чудовищем 275 - это была (вероятно, до сих пор) сеть операторов if и switch, которая была слишком сложной. Единственная реальная ценность - это шаг вперед, когда они решат перестроить систему.

Исключениями из высокого CC, с которыми я был доволен, были фабрики; IMO, они должны иметь высокий CC, но только если они только создают и возвращают простые объекты.

После того, как понял , что это значит, я начал использовать его на" пробной "основе. Пока что я обнаружил, что это полезно, потому что обычно высокий CC идет рука об руку с Arrow Anti-Pattern , что затрудняет чтение и понимание кода. У меня еще нет фиксированного числа, но NDepend предупреждает обо всем, что выше 5, что похоже на хорошее начало для исследования методов.

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

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

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

Да, мы используем его, и я тоже нашел его полезным. У нас есть большая база устаревшего кода, который нужно приручить, и мы обнаружили тревожную высокую цикломатическую сложность. (387 в одном методе!). CC указывает вам прямо на области, которые стоит рефакторировать. Мы используем CCCC в коде C ++.

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

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

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