Solve code complexity (in Go) Part 3

Introduction

Please read the other two posts first to get an idea of what this is about.
Part 1

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.

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.

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.