Как измерить сложность файла C ++ или Java?
Я хочу начать измерять то, что Майкл Фезерс назвал турбулентностью кода, а именно отток против сложности.
Для этого мне нужно измерить сложность файла C ++ или Java. Итак, я нашел пару инструментов, которые измеряют цикломатическую сложность (CC). Каждый из них хорошо измеряет CC на уровне функции или метода. Тем не менее, мне нужен показатель на уровне файлов, и они не так хорошо там. Один инструмент просто возвращает среднее значение всех сложностей методов в файле, а другой инструмент обрабатывает весь файл, как будто это один гигантский метод, то есть он подсчитывает все точки принятия решения во всем файле.
Поэтому я провел некоторое исследование и обнаружил, что McCabe определяет CC только в терминах модулей — и они определяют модуль как функцию, а не как файл (см. Слайды 20 и 30 эта презентация). И я думаю, что это имеет смысл.
Так что теперь у меня есть попытка выяснить, как представить сложность файла. Я думаю, что я должен просто использовать максимальный метод CC для этого файла.
Есть мысли об этом подходе или какие-либо другие предложения?
Спасибо!
кругозор
Решение
Несколько лет назад у меня был тот же вопрос. Я ответил на это следующим образом, и это сработало и работает для меня отлично:
Целью минимизации сложности является улучшение ремонтопригодности. Цикломатическая сложность является показателем логической сложности, и вы правы — она применяется к наименьшей «единице», то есть функции. Можно получить «сводные» метрики, например, total / max / min / и т. Д., Но они редко показывают что-то полезное, когда речь идет о цикломатической сложности. Я попытался использовать «сводные» метрики для сравнения двух баз кода, но пришел к выводу, что здесь действительно полезны только графы распределения цикломатической сложности.
Итак, что можно использовать, чтобы указать что-то об уровне обслуживания для больших единиц / уровней абстракций, таких как файлы / компоненты / подсистемы? Я обнаружил, что первая метрика — это размер единицы в строках кода. Если вы ограничите размер файла, например 1000 строк, и ограничите цикломатическую сложность для каждой функции в файле, у вас будет относительно «простой» файл, потому что он «маленький» и содержит только «простые» функции. Вы можете включать или исключать комментарии / пустые строки или считать только операторы или только исполняемые строки …
Тем не менее, я пришел к выводу, что это не имеет особого значения в этом конкретном приложении. Просто ограничьте некоторую метрику «размера», и она будет служить цели в большинстве случаев. Позже вы можете подумать об ограничении общего количества строк кода на компонент / подсистему. Это будет иметь тот же эффект — компонент «простой», поскольку содержит «небольшое» количество «простых» файлов.
Пост, на который вы ссылались, очень хорош. Его можно расширить до более широкой метрики, которая обычно называется «индексом поддерживаемости». Индекс очень высокий, если функция сложная, файл большой и часто меняется, мало тестируется и т. Д. (Добавьте сюда все, что, по вашему мнению, определяет удобство обслуживания). Я знаю, что это лучший способ найти горячие точки для ре-факторинга …
Отказ от ответственности: Я присматриваю Metrix ++ Инструмент, который выполняет сценарий сценария использования, я объяснил выше.
Другие решения
Других решений пока нет …