Цикломатические диапазоны сложности [закрыто]

27

Каковы категории цикломатической сложности? Например:

1-5: легко обслуживать
6-10: сложно
11-15: очень сложно
20+: приближается невозможно

В течение многих лет я исходил из предположения, что 10 был пределом. И все, что за этим плохо. Я анализирую решение и пытаюсь определить качество кода. Конечно, цикломатическая сложность - не единственное измерение, но оно может помочь. Существуют методы с цикломатической сложностью 200+. Я знаю, что это ужасно, но мне любопытно узнать о нижних диапазонах, как в моем примере выше.

Я нашел это :

Вышеупомянутые эталонные значения Карнеги-Меллона определяют четыре грубых диапазона значений цикломатической сложности:

  • методы от 1 до 10 считаются простыми и понятными
  • значения между 10 и 20 указывают на более сложный код, который все еще может быть понятным; однако тестирование становится более трудным из-за большего количества возможных ветвей, которые может занять код
  • значения от 20 и выше типичны для кода с очень большим числом потенциальных путей выполнения и могут быть полностью изучены и протестированы только с большими трудностями и усилиями
  • методы, идущие даже выше, например> 50, безусловно, не поддерживаются

При запуске метрик кода для решения результаты отображаются зелеными для всего, что ниже 25. Я не согласен с этим, но я надеялся получить другие данные.

Существует ли общепринятый список диапазонов для цикломатической сложности?

Боб Хорн
источник
2
Вы нашли данные из Института разработки программного обеспечения, организации, которая признана лидером в разработке программного обеспечения. Я не понимаю, в чем ваш вопрос - вы нашли список диапазонов для цикломатической сложности. Что еще ты ищешь?
Томас Оуэнс
1
Я видел различные диапазоны; это был только один пример. И MS показывает «зеленый» для всего младше 25 лет. Мне было интересно, был ли один принятый список диапазонов. Возможно, я нашел это тогда.
Боб Хорн
1
Я согласен с @ThomasOwens, но я рад, что вы задали этот вопрос. Я проголосовал за это как за вопрос, так и за ответ.
Evorlor
1
Во 2-м издании «Завершенного кода» Стива Макконнелла он рекомендует, чтобы цикломатическая сложность от 0 до 5, как правило, была в порядке, но вы должны знать, если сложность начинает достигать диапазона от 6 до 10. Кроме того, он объясняет, что при сложности более 10 вы должны серьезно подумать о рефакторинге своего кода.
GibboK

Ответы:

19

Я полагаю, что это зависит от возможностей вашего программиста, и в немалой степени от ваших чувств как менеджера.

Некоторые программисты являются убежденными сторонниками TDD и не будут писать код без предварительного написания модульного теста. Другие программисты вполне способны создавать совершенно хорошие, без ошибок программы без написания ни одного модульного теста. Уровень цикломатической сложности, который может выдержать каждая группа, почти наверняка существенно изменится.

Это субъективная метрика; оцените настройки вашего решения Code Metrics и настройте его так, чтобы вам было комфортно, и это дает ощутимые результаты.

Роберт Харви
источник
3
Договорились, кроме того, все зависит от того, что является причиной сложности. Большой оператор switch, который вызывает другие функции, как часть конечного автомата или чего-то подобного, может иметь очень высокую сложность, несмотря на то, что может быть фактически тривиальным для понимания.
whatsisname
1
Разве заявления о большом переключении обычно не указывают на отсутствие принципов ООП, таких как полиморфизм? Конечные автоматы могут быть реализованы элегантными способами, с ООП или шаблонами проектирования. Нет?
Боб Хорн
3
Для некоторых проблем «элегантность» полезна, а для других она только сбивает с толку. Там нет серебряной пули.
whatsisname
1
-1 Для «Другие программисты вполне способны создавать совершенно хорошие, без ошибок программы без написания ни одного модульного теста». Вы не можете знать, свободна ли эта ошибка, если вы ее не тестировали.
Себастьян
1
@Sebastien: отсутствие модульных тестов не означает, что они не проверены. И да, если вы достаточно хороши, абсолютно возможно написать безошибочный код без тестов или элементарного теста дыма. По общему признанию, эти люди - редкая порода.
Роберт Харви
10

Нет предопределенных категорий, и классификация невозможна по нескольким причинам:

  1. Некоторые методы рефакторинга просто переносят сложность из одной точки в другую (не из вашего кода в среду или хорошо протестированную внешнюю библиотеку, а из одного места в другое в кодовой базе). Это помогает снизить цикломатическую сложность и помогает убедить вашего босса (или любого человека, который любит презентации с постоянно растущей графикой), что вы потратили время на создание чего-то замечательного, но код остается таким же плохим, как и раньше.

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

  3. Некоторые другие методы без рефакторинга вообще не влияют на цикломатическую сложность, при этом значительно снижая сложность кода для разработчиков. Примеры: добавление соответствующих комментариев или документации. «Модернизация» кода с использованием синтаксического сахара.

  4. Есть просто случаи, когда цикломатическая сложность не имеет значения. Мне нравится пример, приведенный whatsisname в его комментарии : некоторые крупные switchоператоры могут быть предельно понятными, а переписывание их более понятным способом не будет очень полезным (и усложнит понимание кода новичками). В то же время эти заявления представляют собой катастрофу с точки зрения цикломатической сложности.

  5. Как уже сказал Роберт Харви , это зависит от самой команды.

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

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

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

Арсений Мурзенко
источник
2
+1 Я согласен со всем сказанным. Цикломатическая сложность или LOC - это просто метрики, которые передаются вам статическим анализом кода. Статические анализаторы являются отличными инструментами, но им не хватает здравого смысла. Эти метрики должны обрабатываться человеческим мозгом, предпочтительно тем, который принадлежит опытному программисту. Только тогда вы сможете определить, является ли конкретная часть программного обеспечения излишне сложной.