Метрики кода — цикломатическая сложность

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

Пример

Цикломатическая сложность определяется как измерение "объема логики принятия решений в функции исходного кода" NIST235. Проще говоря, чем больше решений, которые должны приниматься в коде, тем сложнее.

Давайте увидим его в действии. Создайте новое консольное приложение и сразу же вычислите метрики кода, перейдя в Анализ > Вычисление метрик кода для решения.

пример сложности цикломатики

Обратите внимание, что сложность цикломатики составляет 2 (возможно, наименьшее значение). Если вы добавляете код, отличный от принятия решений, обратите внимание, что сложность не изменится:

пример сложности цикломатики

При добавлении решения значение цикломатической сложности увеличивается на один:

пример сложности цикломатики

При изменении оператора if на оператор switch с четырьмя вариантами выбора количество вариантов увеличивается с двух до шести.

Давайте рассмотрим (гипотетические) более крупные базы кода.

Обратите внимание, что большинство элементов, когда вы углубляетесь в класс Products_Related, имеют значение единицы, но у пары из них сложность равна пяти. Само по себе это различие может быть не большой проблемой, но учитывая, что большинство других членов имеют один в одном классе, вы должны определенно посмотреть ближе к этим двум элементам и увидеть, что в них. Вы можете сделать более подробный взгляд, щелкнув элемент правой кнопкой мыши и выбрав Перейти к исходному коду в контекстном меню. Внимательно изучите Product.set(Product):

пример сложности цикломатики

Учитывая все операторы if, вы можете увидеть, почему цикломатическая сложность равна пяти. На этом этапе вы можете решить, что этот результат является приемлемым уровнем сложности, или вы можете провести рефакторинг, чтобы сократить сложность.

Магическое число

Как и во многих метриках в этой отрасли, нет точного предела сложности цикломатики, которая соответствует всем организациям. Однако NIST235 указывает, что ограничение 10 является хорошей отправной точкой:

"Точное число, используемое в качестве ограничения, однако, остается несколько спорным. Первоначальный предел 10, предложенный Маккейбом, имеет существенные доказательства, но ограничения до 15 также успешно использовались. Ограничения более 10 должны быть зарезервированы для проектов, имеющих несколько операционных преимуществ в отношении типичных проектов, например опытных сотрудников, формального проектирования, современного языка программирования, структурированного программирования, пошагового руководства кода и комплексного тестового плана. Другими словами, организация может выбрать ограничение сложности больше 10, но только если он уверен, что он знает, что это делает и готов посвятить дополнительные усилия по тестированию, необходимые более сложным модулям" NIST235

Цикломатическая сложность и номера строк

Простое рассмотрение количества строк кода само по себе, в лучшем случае, является лишь очень общим индикатором качества кода. Существует некоторая основная правда в том, что больше строк кода в функции, тем более вероятно, что у нее есть ошибки. Однако при объединении цикломатической сложности с строками кода у вас есть гораздо более четкое представление о потенциале ошибок.

Как описано Центром технологий Software Assurance (SATC) в НАСА:

"SATC обнаружила, что наиболее эффективная оценка является сочетанием размера и (цикломатической) сложности. Модули с высокой сложностью и большим размером, как правило, имеют самую низкую надежность. Модули с небольшим размером и высокой сложностью также представляют риск для надежности, так как они, как правило, очень лаконичны, что затрудняет их изменение или модификацию." SATC

Анализ кода

Анализ кода включает категорию правил обслуживания. Дополнительные сведения см. в правилах обслуживания. При использовании устаревшего анализа кода набор правил расширенного руководства по проектированию содержит область обслуживания:

В области поддерживаемости есть правило относительно сложности:

Это правило выдает предупреждение, когда цикломатическая сложность достигает 25, поэтому она может помочь избежать чрезмерной сложности. Дополнительные сведения о правиле см. в CA1502

Объединение всего вместе

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

Цитаты

MCCABE5

Маккейб, Т. и А. Уотсон (1994), сложность программного обеспечения (CrossTalk: Журнал оборонной программной инженерии).

NIST235

Уотсон, А. Х., & Маккейб, Т. Д. (1996). Структурированное тестирование: методология тестирования с помощью метрики цикломатической сложности (специальная публикация NIST 500-235). Получено 14 мая 2011 г. на веб-сайте McCabe Software: http://www.mccabe.com/pdf/mccabe-nist235r.pdf

SATC

Розенберг, Л., Хаммер, Т., Шоу, Джей (1998). Метрики программного обеспечения и надежность (материалы международного симпозиума IEEE по проектированию надежности программного обеспечения). Получено 14 мая 2011 г. на веб-сайте Университета штата Пенн: https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159