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

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

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

Как вся метрика программного обеспечения, CC не прекрасен. Используемый на достаточно большой кодовой базе, это может дать Вам общее представление о том, где мог бы быть проблематичной зоной.

существует две вещи иметь в виду здесь:

1. Достаточно большая кодовая база: В любом не тривиальный проект у Вас будут функции, которые имеют действительно высокое значение CC. Настолько высоко, что не имеет значения, если бы в одном из Ваших примеров, CC был бы 2 или 3. Функция с CC скажем, более чем 300 является определенно чем-то для анализа. Не имеет значения, ли CC 301 или 302.
2. не забывают использовать Вашу голову. Существуют методы, для которых нужны много моментов принятия решения. Часто они могут быть пересмотрены так или иначе, чтобы иметь меньше, но иногда они не могут. Не идите с правилом как, "Осуществляют рефакторинг все методы с CC> xy". Взгляните на них и используйте мозг для решения, что сделать.

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

Это - опасность применяться любой метрика вслепую. Метрика CC, конечно, имеет большую заслугу, но как с любой другой техникой для улучшения кода она не может быть оценена разведенная от контекста. Укажите Ваше управление при обсуждении Casper Jone Строк измерения кода (жаль, что я не мог найти ссылку для Вас). Он указывает, что, если Строки кода хорошая мера производительности затем, ассемблерные разработчики языка являются самыми продуктивными разработчиками на земле. Конечно, они не более продуктивны, чем другие разработчики; просто им требуется намного больше кода для выполнения то, что высокоуровневые языки делают с меньшим количеством исходного кода. Я упоминаю это, как я говорю, таким образом, можно показать менеджерам, как немой это должно вслепую применить метрики без интеллектуального обзора того, что метрика говорит Вам.

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

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

То же с цепочечной IFS в примере 2 - эта структура позволяет Вам иметь statment, который был бы выполнен, если только condition1 и condition2 верно. Это - особый случай, который не возможен в случае с помощью & &. так, если - цепочка имеет больший потенциал для особых случаев, даже если Вы не используете это в своем коде.

[Вне темы], Если Вы одобряете удобочитаемость по хорошему счету в метриках (Было это J.Spolsky, который сказал, "что измеряется, доберитесь, сделал"? - подразумевать, что метриками злоупотребляют, как правило, я предполагаю), часто лучше использовать хорошо названную булевскую переменную для замены сложного условного оператора.

затем

if (condition1 && condition2 && condition3)
    Console.WriteLine("wibble");

становятся

bool/boolean theWeatherIsFine =  condition1 && condition2 && condition3;

if (theWeatherIsFine)
    Console.WriteLine("wibble");

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

Когда я проверяю код существующего приложения, я считаю цикломатическую сложность полезной метрикой «отправной точки». Первое, что я проверяю, это методы с CC> 10. Эти методы «> 10» не обязательно плохие. Они просто дают мне отправную точку для просмотра кода.

Общие правила при рассмотрении номера CC:

• Связь между CC # и # тестов должна быть CC # <= #tests
• Рефакторинг CC # только в том случае, если он увеличивается. ремонтопригодность
• CC выше 10 часто указывает на один или несколько запахов кода