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

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

Пример

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

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

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

Если добавить решение, значение сложности цикломатики увеличивается на 1:

При изменении инструкции if на оператор switch с 4 решениями, которые необходимо принять, он переходит от исходного 2 до 6:

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

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

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

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

Как и во многих метриках в этой отрасли, нет точного ограничения сложности цикломатики, которое соответствует всем организациям. Однако 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