Понижаем цикломатическую сложность без смс и регистрации

Под конец года все больше разговоров про цикломатическую сложность и ее устранение. Собственно, рассмотрим это чудо юдо вблизи и определимся, как будем с ним бороться. По базе это мера "запутанности" кода и вычисляется она по простой формуле M = E - N + 2P. Где E - кол-ло управляющих операторов (if, else, while ...), N - кол-во операций в блоке, а P - элемент связанности (обычно 1 для функции). Это если говорить обобщенно, вообще объяснение дается на графе управления программы, но если делать абстракцию до кода, то это примерно то, что я описал.

Держать сложность в идеале в пределах 3-4. Если у вас везде единица, то вы либо пишите бизнес код, либо код на Go или C по заветам Дейкстры. Но как ее понижать то?

Во-первых, никаких if, switch, циклов и проверок на null. Казалось бы, это противоречит здравому смыслу, ведь программы состоят из циклов, ветвлений и исполнения. Но кто сказал, что циклы и ветвления обязаны быть конструкциями языка?

Параметрический или ad-hoc полиморфизм (у нас все же мир энтерпрайз ООП), карты исполнения (хэшпамы со значениями в виде замыканий), тернарный оператор - это только то, что я вспомнил на холодную голову, чем можно заменить ветвление. С циклами сложнее, так как тут есть только функция map, которая внутри все тот-же цикл.

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

Но мы же программисты и хотим все считать без составления графом, что бы автоматически. Здесь нам поможет SonarQube, который сделает это за нас. Вещь прикольная, она легко встраивается в CI/CD, может висеть просто докер образом и легко встраивается в IDE. Рекомендую попробовать всем.

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