Comments 4
Не очень эта ваша метрика, сами смотрите, в вашем же примере парсера я могу заменить ифы где сравнивается символ с константой на таблицу делегатов где символ будет индексом в таблице. Таким образом уйдут штрафы за часть ифов. Альтернатива иерархия наследования с виртуальными методами.
Дальше сложные условные выражения в других ифах (где за каждое подвыражение +1 штрафа) я могу разбить на составные части и результаты записать как пару результат подвыражения и как сворачивать делегат/лямбда конъюнкция/дизъюнкция в масив над которым потом сделать свертку. Вероятней всего за свертку я вообще штраф не получу ну или единицу так как там внутри будет ровно один обычный фор. Короче говоря я просто расчехлю функциональное программирование по полной программе (если вы не в курсе, то в лямбда исчислении вообще нет ифов и форов, все на лямбдах).
После такого рефакторинга ваша метрика уменьшится, но вот будете ли вы довольны?
Но представленный пример выглядит как попытка «обыграть» программу, которая лишь пытается помочь. Это один из инструментов автоматически (и быстро) показывающий потенциальные проблемы. Никто не отменял код ревью, на котором ревьювер тыкнет носом в «накрученную» логику.
Важно не забывать в чем цель. Если цель не в качественном отражении логики в коде, а в том чтобы не получить штрафов, то как по мне это довольно странно.
Ну тут или продолжать сложность определять "на глаз", или вводить метрику.
Если при наличии метрики всё равно приходится "на глаз" определять, то какие цели преследует её введение в рассмотрение? Для чего она вообще такая нужна, если настолько хрупкая?
Ниже я привёл пример того, насколько легко она ломается в языках с поддержкой ФП. Да, конкретно этот пример несколько искуственный, но всевозможные пользовательские управляющие конструкции в ФП коде кругом и рядом, то есть для типичного ФП кода метрика будет регулярно занижать оценку.
Метрика не подходит для современных языков, поддерживающих ФП, так как ФП позволяет программисту реализовывать свои управляющие конструкции. Ниже пример на Kotlin, где представлена пара реализаций для конструкций изоморфных if else, которые "ломают" расчёт сложности для функций test2 и test3.
Вывод: в текущем виде мало кому нужна, так как почти все современные популярные ЯП поддерживают ФП.
Метрика Cognitive complexity или простой способ измерить сложность кода