Метрики кода — цикломатическая сложность
При работе с метриками кода одна из наименее понятных элементов, кажется, цикломатическая сложность. По сути, с цикломатической сложностью, более высокие числа плохие и низкие числа хороши. Вы можете использовать цикломатические сложности, чтобы получить представление о том, насколько сложно любой код может быть тестировать, поддерживать или устранять неполадки, а также указывать на вероятность того, как код будет создавать ошибки. На высоком уровне мы определяем значение цикломатической сложности, подсчитывая количество решений, принятых в исходном коде. В этой статье вы начинаете с простого примера цикломатической сложности, чтобы быстро понять концепцию, а затем ознакомьтесь с дополнительными сведениями о фактическом использовании и предлагаемых ограничениях. Наконец, есть раздел ссылок, которые можно использовать для более глубокого анализа этой темы.
Пример
Цикломатическая сложность определяется как измерение "объема логики принятия решений в функции исходного кода" 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