Solve code complexity (in Go) Part 4

go dev.to

Introduction

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

And then, one morning, I asked myself the following question:

What if I could lint more than just Go programs? I was still in bed when this popped in my head and I started to smile.

If you read until the very end, the conclusion is the actual important part.

Nina Simone

Immediately Nina Simone started singing her famous song in my head "Feeling Good". In that song there is this sentence: "It's a new dawn, it's a new day, it's a new life for me, and I'm feeling good."
This was actually the reason I was smiling. I saw an opportunity, a challenge, this day would be a refactor day of what I had, into a multi- purpose cognitive linter for more than just the Go language.

Silence before the storm

I showered, got dressed and walked the dog. That moment in my day, outside, gives me a peace of mind and the calmness to think about the things I needed to change in the program. It's like when I sail my sailboat and further away, there is a storm coming. You estimate when, where, how it will hit. Which adjustments you have to make to cope with it. It is all the same, just the narrative is different.

Refactor Padawan

As I am always learning, because my surroundings change, I see myself as a student, even though I am a Principal Software Engineer. I learn all the time. And so I did today. As it turned out, my program was easy to refactor (because there were no complex parts gheghe).

PHP

I think, that after 1 hour or so, I was capable of checking a PHP program (that I wrote years ago). It was checked and a report came out of that as expected. I am ashamed to admit, that the quality of that older PHP program was not up to my standards I use nowadays. My excuse, it was over 10 years ago ;-)

The report summary looks like this:
82 = files
422 = functions
8127 = function lines
26 = complex functions
1162 = complex function lines
6.16 % are complex functions
14.30 % of lines belong to complex functions
3.55 = overall average complexity per function

38 = highest complexity

Rust

I don't have Rust experience yet, so I decided to pick a popular project and ended up checking zeroclaw.

The report summary looks like this:
1083 = files
36079 = functions
745613 = function lines
645 = complex functions
102387 = complex function lines
1.79 % are complex functions
13.73 % of lines belong to complex functions
2.06 = overall average complexity per function

414 = highest complexity

Python

I didn't want to pick a python project of my own, so I decided to pick a popular Python project and ended up checking ai-job-search.

The report summary looks like this:
10 = files
66 = functions
1522 = function lines
18 = complex functions
970 = complex function lines
27.27 % are complex functions
63.73 % of lines belong to complex functions
14.36 = overall average complexity per function

161 = highest complexity

Java

I decided to pick an ancient Java project of mine, made in... 2001. I can only say as an excuse, that I have grown since then hahaha.

The report summary looks like this:
32 = files
265 = functions
11011 = function lines
63 = complex functions
7402 = complex function lines
23.77 % are complex functions
67.22 % of lines belong to complex functions
12.11 = overall average complexity per function

109 = highest complexity

Eat my own dogfood

I know that some developers might be curious about the cognitive code quality of this linter.
To me, it is no surprise that my reports shows me that I've done my very best:
17 = files
115 = functions
1887 = function lines
0 = complex functions
0 = complex function lines
3.50 = overall average complexity per function

9 = highest complexity

Conclusion

My mantras about software development are written down in previous posts about this subject, but I will repeat my very own:

To write code is easy, to write understandable, maintainable code is hard.

And if you look at the numbers of the reports, they all tell me the same: The code is too complex! This makes it harder for other people to step in and offer their help. If you want your code to survive, then you have to consider that you keep the maintainability level high.

A good maintainable program is not only easy to maintain, it had less bugs and is also much better to understand. This will help with the acceptance to use it.

Source: dev.to

arrow_back Back to Tutorials