Solve code complexity (in Go) Part 1
Tags: go
Published: 2023-10-19 08:37:12

---
title: Solve code complexity (in Go) Part 1
published: true
description: Looking for maintainable software?
tags: go
# cover_image: https://direct_url_to_image.jpg
# Use a ratio of 100:42 for best results.
# published_at: 2023-10-19 06:45 +0000
---
![spaghetti coding](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wt3mni2frfnrzmh512xc.jpg)

## Introduction

People who know me, know I'm a fan of the KISS principle (Keep It Stupid Simple). To me, this means if you write maintainable software that is so easy to understand, that even "the new kid on the block" can do some changes on it, without breaking it (I'll hope). Or your future self is probably grateful for the simplicity of the stuff you have made in the past.

## Genius at work

Sometimes you're just busy implementing the latest idea into your code, or the companies code for that matter. As long as everything works according to specifications, you're good.

If you're lucky, you have that critic of a co-worker, who can point you to some nasty stuff you did. But to have that colleague, or to become your own critic, can take time.

Perhaps I can be of help?

## Cognitive code complexity

Ever heard of cognitive code complexity? I've read about it a couple of years ago and I was intrigued.

Cognitive code complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and understand.

I decided to implement it in my own linter and followed the idea of one of the studies.

## How it works

Imagine that each if-statement within a function adds up to the complexity of that function.
```
 complexity = 1
  + 1 (found 'if' at line: 159, complexity = 2)
```

We can look at more recognisable parts that will make the code more complex:
* AssignStmt
* BlockStmt
* BranchStmt
* CaseClause
* DeferStmt
* ForStmt
* GoStmt
* IfStmt
* RangeStmt
* SwitchStmt
* TypeSwitchStmt

Well, it isn't that simple! Because, you will encounter nested statements. I actually add the depth of a statement to the complexity. (You can see in the following example)
```
mytube.go:57:1 - isPartialMatch has complexity: 4
  complexity = 1
  + 1 (found 'range' at line: 61, complexity = 2)
    + 2 (found 'range' at line: 62, complexity = 4)
```

## He's clever!

This is a bit how most of the studies go about cognitive code complexity and I blindly followed their findings and advices.

When I finished my implementation, I proudly showed it to my son. He must have been about 18 years old at the time, studying to become a frontend developer.

He'd asked some questions about the inner-working when he popped "the question" which made all (or most) studies look bad.

I don't recall the exact question anymore, because that was about 5 years ago, but it was something along the lines of "Would you agree that an if-statement with a little content is less difficult than an if-statement with more content?"

I'm so proud of him. He proved to be as clever as his dad :-)
Perhaps even more clever, because I didn't think of that before, when I was a blind follower of people with a degree. 

## Challenge accepted

Ok, so my linter had to change to make it a bit more along the lines of "the question". It wasn't that hard to do and in a couple of free hours, I fixed it. It did run flawlessly and for the projects I'd tried it upon, I could tell in no-time where the pain-points were.

## Looking for a job

Since I'm looking for a job and have some spare time at my disposal, I began to think about cognitive code complexity again.

I decided to make a separate linter with the same functionality, so people can enjoy this one day. It would be awesome, if you can pinpoint the functions that needs refactoring, all by yourself. You could make "the new kid on the block" or your future self happy! (Strike 1)

You'll even make your boss or company happy, because the maintenance costs will drop if the software will follow the KISS principle more. (Strike 2)

The chance that "KISS" software will survive a couple of years is much higher than "clever, but complex" software. (Strike 3)

## Next steps

I tested it on some projects I like and gave them some stuff to think about. One project lowered the complexity from the highest being 27 to now a 12. (I consider 12 something "the new kid" can understand.)

It's ready enough to test it out in the open, but not ready enough for others to use it.

For now, it means that you can drop me a message (on here or on LinkedIn: see my profile) with the url of your git repository and I will get you your report.

But... if I get a lot of projects to lint, I might not help you that fast. Also I do some analyses on the linters findings, if it works as it should.

If you reached this line, thanks for reading!

[Part 2](https://dev.to/marcello_h/solve-code-complexity-in-go-part-2-5a5l)