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

Я хочу начать измерение того, что Майкл Фезерс назвал турбулентностью кода, а именно отток по сравнению со сложностью.

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

Поэтому я провел небольшое исследование и обнаружил, что Маккейб определяет CC только в терминах модулей, а они определяют модуль как функцию, а не как файл (см. google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCoQFjAA&url=http%3A%2F%2Fwww.rivier.edu%2Ffaculty%2Fvriabov%2FCS699_McCabe_Overview.ppt&ei=o8NMUtikC4TCywG4p4DAAQ&usg=AFQjCNH_KmduonpB78Wbx4LJuc5gfPNcWQ&sig2=oLS16awUouU39N8eb1HY4A&bvm= bv.53537100,d.aWc" rel="noreferrer">данная презентация). И я думаю, что это имеет смысл.

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

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

Спасибо!

Кен


c++ java code-metrics churn cyclomatic-complexity
person Kenneth Klein    schedule 03.10.2013    source источник
comment
Вероятно, вам следует перейти на programmers.stackexchange.com. StackOverflow предназначен для решения конкретных вопросов.   -  person Jeroen Vannevel    schedule 03.10.2013

Ответы (1)


arrow_upward
4
arrow_downward

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

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

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

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

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

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

person Andrew    schedule 03.10.2013
comment
Few years ago I had the same question Было ли это отправной точкой Metrix++? Он все еще поддерживается (кажется, домашняя страница новая)? - person Wolf; 27.05.2016
comment
Это не было отправной точкой, я расширял, когда мне было нужно. Я не добавлял новых функций последние 2 года, но я просто использую его, поскольку он работает и делает то, что мне нужно. - person Andrew; 29.05.2016