whack-a-mole
find the perl subroutine most in need of refactoring
fix it
repeat... virtuous whack-a-mole with https://github.com/wickline/whack
find the perl subroutine most in need of refactoring
fix it
repeat... virtuous whack-a-mole with https://github.com/wickline/whack
hmmm
This looks interesting. Just ran it on some of my code and it seems to find the complicated subs.
Hm, is it really better than running Perl::Critic with
Perl::Critic::Policy::Subroutines::ProhibitExcessComplexity policy enabled ?
I wasn't aware of ProhibitExcessComplexity or the McCabe score, so thanks for the reference. Looking at the source for Perl/Critic/Utils/McCabe.pm, I can tell you that they're not measuring the same things, but the two scores are probably likely to correlate in many cases.
I'll take a closer look when I've got time and may tweak whack.pl some based on what I see there, but I can also see that there are some things I'd like to keep different.
Also, I'm used to using PerlCritic as a pass/fail sort of tool. Some unit of code is either good enough or not. There is no affordance for talking about relative quality other than "this code passes/fails and the other does not". So, the main difference of whack.pl is that it is intended to say "these are the bits of code that are the worst" so that you can improve them. You can decide in advance how much effort to invest in improving them by saying "I want them to be at least as good as that bit of code over there" (or equivalently, "I want them out of the top-N").
I suppose one could use PerlCritic in a similar fashion by tweaking the max_mccabe parameter and lowering it below X as you found that you got everything passing at value X.