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

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

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

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

Я нашел это :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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