Распространенные причины цикломатической сложности и способы их устранения

Question

На работе мы смотрим на общие проблемы, которые приводят к высокой цикломатической сложности. Например, наличие большого оператора if-else может привести к высокой цикломатической сложности, но может быть решено путем замены условных выражений полиморфизмом. Какие еще примеры вы нашли?

Answer 1

См. Определение цикломатической сложности NDepend .

Глубина вложения также является отличной метрикой кода.

Цикломатическая сложность является популярной процедурной метрикой программного обеспечения, равной числу решений, которые могут быть приняты в процедуре. Конкретно, в C # CC метода равен 1 + {число следующих выражений, найденных в теле метода}:

если | в то время как | для | foreach | дело | по умолчанию | продолжить | Перейти к | && | || | поймать | троичный оператор?: | ??

Следующие выражения не учитываются при вычислении CC:

еще | делать | переключатель | попробуй | используя | бросить | наконец-то | возврат | создание объекта | вызов метода | доступ к полю

Адаптированный к миру ОО, этот показатель определяется как для методов, так и для классов / структур (как сумма его методов CC). Обратите внимание, что CC анонимного метода не учитывается при вычислении CC его внешнего метода.

Рекомендации: методы, в которых CC выше 15, трудно понять и поддерживать. Методы, где CC больше 30, чрезвычайно сложны и должны быть разбиты на более мелкие методы (кроме случаев, когда они автоматически генерируются инструментом).

Answer 2

Еще один пример, позволяющий избежать использования множества if, - это реализация конечного автомата. Поскольку события инициируют переходы, условные обозначения более явно неявно связаны с этими переходами, которые изменяют состояние Системы. Управление проще.

Оставьте вам ссылку, где упоминаются некоторые из ее преимуществ:

http://www.skorks.com/2011/09/why-developers-never-use-state-machines/