Don’t analyze your code
Tags: openedge, progress, coding, datadigger
Published: 2019-12-01 20:10:01

---
title: Don’t analyze your code
published: true
date: 2019-12-01 20:04:52 UTC
tags: OpenEdge, Progress, Coding, DataDigger
canonical_url: https://datadigger.wordpress.com/2019/12/01/dont-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.

![spgTHgA[1]](https://datadigger.files.wordpress.com/2019/12/spgthga1.png)

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.

![ox2ywSK[1]](https://datadigger.files.wordpress.com/2019/12/ox2ywsk1.png)

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](http://sonar.riverside-software.fr/dashboard?branch=develop&id=patrickTingen%3ADataDigger) site.

Since the DataDigger development branch is quite clean now, you can compare it to the [master branch](http://sonar.riverside-software.fr/dashboard?branch=master&id=patrickTingen%3ADataDigger), 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](https://datadigger.wordpress.com/2019/12/01/dont-analyze-your-code)_