Code Quality vs Cheat Codes
Posted by Denny at 22:51 on Fri, 23 Apr 2021
I've been using Ruby Critic to track code quality metrics for a while now (both in work projects and personal projects, although I tend to get more time for fixing the things it highlights in the personal ones). One thing that has been annoying me in this particular project is that, between the 'convention over configuration' approach of Rails, and the 'built up from common roles and patterns' approach I've tried to take with the ShinyCMS plugins, there are a few areas of the code that get a bad score from flay, the tool used by Ruby Critic to look for duplicate code.
The reason for a duplicate code scan, is that often duplicate code is a prime candidate for being factored out into a common method or similar. But in the case of ShinyCMS, most of what it's detecting is the way that, for example, a skinny Rails controller tends to have the same few RESTful actions, doing the same checks with the same consequences, and really only the names of the constants and variables tend to change sometimes. I could factor that out, but it would make those controllers much less conventional, and hence harder for other people to work on - pretty much the opposite of what I want to achieve!
So, I finally got around to looking at the flay documentation a few days ago, and then I added a `.flayignore` file to skip checking controllers and policies for duplication. This had a quite noticeable effect on the lower-scoring files in my Ruby Critic summary - the D and F grades - in fact it got rid of every single one of them.
I wasn't expecting it to be quite that dramatic. And now, instead of feeling like I've made the scores a more useful and realistic indication of the actual quality of the code ... I just feel like I've used a cheat code. :)
Tags: code quality rubycritic config