Scanning code quality with SonarQube

Having started as procedural PHP hobby-programmer somewhere in 2005 the step towards object oriented C# in 2017 was quite large, but it was a step I really enjoyed. Before I took a course in Game Development on Coursera the concept of OOP was clear, but still pretty abstract.

Coming from webdevelopment it was difficult for me to see how OOP would work with objects just living for 1 page view, and I never took the time to properly pick up a framework such as Laravel. When I started on SubSurfer (2d endless-running game with a submarine) the pieces started to fall into place and from the point I set up One More Island I think it was clear how things worked.

Now as a Product Manager at TOPdesk and currently Mendix I’ve of course seen Jenkins build-pipelines and the works, but I can tell you that’s vastly different from working with such a thing yourself. Luckily though, one of my friends pointed out a tool to improve my code quality: SonarQube. It basically scans your code – C# in my case – and applies a set of rules to determine the quality.

Ready to be shocked?
This was what the initial run told me: 2.7k code smells, 12 blockers and 196 critical issues. Jeez!! Did I really mess up that bad?

Well, yes and no… Within about 20 hours of programming I managed to get it down drastically, although I do have to admit I also disabled one of the “Major” rules that didn’t allow me to put Debug.Log() in comments in my code 😉

To resolve bad practices in subclasses I finally fully grasped the concepts of Virtual/Override methods and Static/Abstract classes and methods. Additionally I’ve reduced lots of complex functions (deeply nested ifs score you a lot of complexity-points..) and most importantly: lots of public variables where changed to protected or private.
I’m not there yet, but resolving Blocker-Critical-Major batch is something I can start seeing the end of!

So the game is a lot better now, right? The Product Manager in me is hesitant to say “yes” because there are zero new visible features, but the Developer screams “yes”. The code is a lot more maintainable and core classes such as Character are now properly subclassed, where previously it was a weak solution still depending on lots of if-statements in the main class.

Next up is Automatic Testing, another aspect I’ve never spent any time on. You know you should it – but every minute invested in testing is something I can’t invest in short-term features.
Hmm… I see a pattern.