Don’t analyze your code

The DataDigger is an open source database browser for developers in OpenEdge. It enables them to view, update, delete, im- and export the data inside the database. The DataDigger is written fully in OpenEdge 4GL and has over 40,000 lines of code. Inside are some real treasures, so I will dissect the DataDigger, to reveal them. Today: bugs.

My advice may sound strange, but there is a twist. You should not analyze your code YOURSELF. Have it done by someone who can do it much better and faster than you. And that is – obviously – a computer.

I am the main developer for the DataDigger and since it is a hobby project, I have some pride in keeping the code clean, so when Gilles Querret of Riverside software asked me if he could use the DataDigger as a test case for his OE plugin for Sonar, I did not need to think twice. Having it analyzed by Sonar would prove that my code was super clean and that there were only a few minor things to improve.

Boy, was I wrong

Even though the code /was/ quite clean, Sonar still found a lot of issues with the code. A lot of these issues were not very important things. Think of things like variables that are defined and assigned, but never used. Think of LEAVE or NEXT statements without a block label. Think of statements that are combined on one line.

Minor things

Sure, minor things. But they added up. There was a total of over 400 issues that were reported. A lot of them were indeed minor issues, but a few were not. One of the reports of a parameter that was used but never assigned made me frown. Why did I put a parameter in when I did not use it. So I was busy removing it from both the program and the callers, when I suddenly saw that it was not the parameter that was obsolete, but it was the logic that was lacking. A part of the functionality was missing and I had not noticed.

Autch.

But there were more and more small issues that – on a second glance – were perhaps not as small as I thought. Missing labels for NEXT or LEAVE are no problem, as long as you are leaving the right block. When placing labels I found that I left the inner block where I should have left the outer block, resulting in poor performance. Another issue was a ‘dot commented line’. When debugging, I sometimes add a dot before the first statement on a line when debugging. It results in the line being treated as a commented line. That’s fine, but you should remove it when your done. I didn’t.

So there were quite a few issues with the DataDigger. Gilles attached the development branch to Sonar and I started to fix the issues. Now, there is only a handful left that are either hard to fix or wrongly reported.

So, see what Sonar reports on the development branch on the riverside site.

Since the DataDigger development branch is quite clean now, you can compare it to the master branch, which still contains quite a number of issues.

So don’t analyze your code, have it analyzed by Sonar.

This post was previously posted on the DataDigger blog