Solve code complexity (in Go) Part 3
Tags: go
Published: 2023-11-22 09:09:13

---
title: Solve code complexity (in Go) Part 3
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
Please read the other two posts first to get an idea of what this is about. 
[Part 1](https://dev.to/marcello_h/solve-code-complexity-in-go-56hg)

Because of my blog post, I was asked by several people to run my linter on their software. I sometimes did this on projects that didn't ask me to do it. I wanted to lint a lot of different Go-projects, just to check if my linter would report it in the way I expected it.

## Reactions

I remember that when I was just a starting developer (around 40 years ago), when someone would say something about my code, it felt like they were saying something about the most beautiful thing I ever created, so I felt hurt.

Of course, there were a couple of those reactions back, from "Mind your own business!" to "It works, so why bother?".

You can imagine why people would give such answers, and I wish them all the best.
 
Overall, the reactions were positive, even when my linter reported a lot of "painpoints" in the best thing they ever created.

A Go-project was linted of one of the organisers of the Golang Amsterdam Meetup, and I asked him if he was interested in the results. He was, and he reacted quite positively. That led to having a 45-minute presentation at the very next meetup.

## Golang Amsterdam Meetup

As the first presenter, it was nice to tell about my experiences so far. People got an idea about how the linter would look at complexity. I showed the top 3 Go projects that had the highest complexity per function.

And when it was time for questions, I really felt that the audience had understood the idea of my presentation.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ku99wh89o8b4hnewy9z5.png)

Of course, there was the expected one:
"Can you lint your linter to see what the maximum complexity is?".
As I said during the presentation, I like my software to be simple (following the KISS principle) and maintainable, so it was no surprise that the linter has a maximum complexity of 9.

At the end of the Golang Amsterdam Meetup, I was given a Go mug, which is a nice thing to have.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xgnjxdb0182uiaon6fgw.jpeg)


## Numbers

In the presentation, some numbers were shown:

81 not-so-random projects:
* popular ones
* idiomatic ones
* newcomers

The linter analysed 47.601 files and 284.401 functions.
That’s 5.427.312 lines of code inside functions

Findings:
31.029 complex functions with 2.164.305 lines of code.
* about 11 % of all functions are complex
* about 40 % of lines belong to complex function

## Facts / wisdom

In the end, there was a slide with some things to think about when you write software.

* K.I.S.S (Keep It Stupid Simple).
* Complex code can hide bugs easily.
* Don’t be clever; be smart (or wise).
* Code tends to get more complex over time. 
* To write code is easy, to write understandable, maintainable code is hard. (Marcelloh)
* Treat your code the way you want others’ code to treat you.
* Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius, and a lot of courage, to move in the opposite direction. (Albert Einstein)

## The end?

Does this end here? Is this my own little pet-program, that I can use when looking at code?

The questions the people asked, had some really interesting ones between them, so I feel the urge to have some extra options inside.

One simple conclusion is that people don't all look at Go-code  the same way, which is fine with me. If I can "capture" all those differences into a configuration, then the linter would behave the way they need it to.

## The future

Can the linter be tested in a business environment? It will be helpful for a company if they want to write maintainable software that will survive a couple of years.
It will save them so much time and will probably squash some bugs along the way during refactoring that I think it should be worth something.

So that's what I'll be investigating.

The linter needs some reviews, and at the end of the presentation, I asked if there were 3 to 5 companies willing to have me look at their software (in their office) for free in exchange for a review.

I already have one company that will invite me.

If you read this, I can do the same for you, for free, for now, as long as I have the time and if you are willing to write a review about the outcome.