2

Я провел анализ статического кода на нескольких проектах и ​​получил Cyclomatic Complexity для каждого файла в этих проектах из созданного отчета. Теперь я хочу рассчитать среднюю Cyclomatic Complexity для всего проекта.Средняя Cyclomatic Сложность нескольких файлов

Как бы я смог достичь этого?

Просто добавление значений Cyclomatic Complexity для каждого файла, а затем деление на количество файлов кажется мне неправильным, поскольку короткий заголовочный файл будет иметь такое же влияние, как и очень длинный файл. Кроме того, я хотел бы избежать взвешивания важности файла по строкам кода.

Есть ли другой способ сделать это? Например, со средой?

+0

Спасибо за редактирование, это не мой родной язык .... –

ответ

3

Цикломатическая сложность влияет на количество решений в вашем исходном коде. (На самом деле он более сложный, чем в целом, но при этом уменьшается на случай структурированного кода). Он часто вычисляется как # решений + 1, даже в более сложном случае (да, это аппроксимация).

Итак, если у вас есть две меры CC, х и у, с

CC(x)=#decisions(x)+1, 

и

CC(y)=#decisions(y)+1, 

общая

CC(x with y) = #decisions(x)+#decisions(y)+1=CC(x)+CC(y)-1 

Так что если у вас есть N наборов CC данных, хорошее приближение общего CC составляет:

[Sum i=1..n: CC(i)]-(N-1) 

Если вы хотите среднедушевой файл через вашу систему, разделить выше на N.

+0

Это кажется довольно разумным. Я попробую это. Спасибо =) –

0

Из Вашего вопроса, я бы сказал, в первую очередь необходимо определить ваши намерения относительно среднего CC.

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

since a short header file would have the same impact as a very long file 

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

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

0

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

Отказ от ответственности: Я являюсь автором Metrix ++, который делает это.Пожалуйста, проверьте, как выглядит график распределения: http://metrixplusplus.sourceforge.net/workflow.html#workflow_view_summary_section

Смежные вопросы