This week it was time to look at the issues the code metric tool we are using reported and decide whether we should fix them or if there’s a valid reason why the code should stay as it is.
First of all the tool we are using is called Codacy which is hooked up with GitHub and therefore is analysing our code on every push or pull request to the master branch. So it is easier for us to write better code because every time a pull request add issues Codacy complains about it and the owner of the pull request gets blamed.
By using different metrics an overall grade is calculated and displayed in a nice dashboard:
The Refactoring we did this week was pretty easy, in the issue list on Codacy every found issue is listed with a explanation why this is an issue and how it could be fixed. So we went through and fixed some of the issues. Most of them were just code style issues so the code should look better now. To make it visible we packed it in one commit, so you can look easily on the issues fixed:
As you can see here the result was pretty good and the issue counter dropped:
Of course we did not fix issue but mostly the reason is that not every issue is really something we should or could change. A lot of issues are like the following that says avoid using static access to class:
Since we are using a Framework that tells that this is the right way to do so, there’s nothing other to do for us than ignoring these issues!
Codacy uses metrics to find issues of these categories:
- Code Complexity
- Code Style
- Error Prone
- Unused Code
We haven’t found what exact metrics are used internally so it won’t get more specific but if you are interested you can read here how the calculation is done.