Как измерить сложность файлов на C++ или Java?

Question

Я хочу начать измерение того, что Майкл Перс назвал турбулентностью кода, а именно churn vs. complexity.

Для этого мне нужно измерить сложность файла C++ или Java. Поэтому я нашел пару инструментов, которые измеряют циклическую сложность (CC). Каждый из них измеряет CC на уровне функции или метода. Тем не менее, мне нужна метрика на уровне файлов, и они там не очень хорошо. Один инструмент просто возвращает среднее значение всех сложностей метода в файле, а другой инструмент обрабатывает весь файл, как один гигантский метод, т. Е. Он учитывает все точки принятия решения во всем файле.

Итак, я провел некоторое исследование и обнаружил, что МакКейб определяет CC только в терминах модулей - и они определяют модуль как функцию, а не как файл (см. Слайды 20 и 30 из this presentation). И я думаю, что это имеет смысл.

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

Любые мысли об этом подходе или любые другие предложения?

Спасибо!

Ken

Answer 1

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

Целью минимизации сложности является улучшение ремонтопригодности. Цикломатическая сложность является индикатором логической сложности, и вы правы - она ​​применяется к наименьшей «единице», т. Е. Функции. Можно получить «итоговые» показатели, такие как total/max/min/etc, но они редко показывают что-то полезное, когда речь идет о циклической сложности. Я попытался использовать метрики «summary», чтобы сравнить 2 базы кода, но пришел к выводу, что здесь действительно полезны только графики распределения циклической сложности.

Итак, что можно использовать для указания уровня ремонтопригодности для больших единиц/уровней абстракций, таких как файлы/компоненты/подсистемы? Я обнаружил, что первая метрика представляет собой размер единицы в строках кода. Если вы ограничиваете размер файла, например 1000 строк, и ограничиваете циклическую сложность для каждой функции в файле, у вас будет относительно простой файл, потому что он «маленький» и содержит только «простые» функции. Вы можете включать или исключать комментарии/пустые строки или считать только утверждения или только исполняемые строки ...

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

Сообщение, о котором вы говорили, очень хорошо. Он может быть расширен до более широкой метрики, которая обычно называется «индексом ремонтопригодности». Индекс очень высок, если функция сложная, файл большой и имеет частые изменения, небольшое покрытие по тестам и т. Д. (Добавьте сюда все, что, по вашему мнению, определяет ремонтопригодность). Это лучший способ, я знаю, чтобы найти горячие точки для повторного факторинга ...

Отказ от ответственности: Ищу после того, как Metrix++ инструмента, который выполняет сценарий варианта использования, я объяснил выше.