NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Code smell heuristic (Score:2)
Thanks for the heuristic! I never realized that before! I think this will help improve my coding.
(If there's a larger source where you picked that up, I'd be benefitted by a pointer.)
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Re:Code smell heuristic (Score:2)
I figured a concrete example would help. Imagine this awful method from some Catalyst code I was working on:
As you can see, we have a nasty conditional which basically throws away the work previously done. We could turn that into an if/else block and at least ensure that the assignments are only done once, but as it turns out, the core problem was this:
First, we have the problem that the "period" can now be just about anything and we have to manually check it. Second, because we do things manually, we have that nasty if/else block. Instead, I wrote something like this:
That's still pretty ugly, but the '_set_group_by' method goes away and the conditionals are eliminated. It also clarifies the code and groups the needed information together. After a lot of this was done, the simplification was revealing all sorts of underlying problems that our complex code was masking. The big win, though, is that we no longer need to check whether or not our 'period' is valid because that's handled by the method dispatching! (This is obscured in this instance because it's Catalyst, but Catalyst really can save you a lot of pain here)
Reply to This
Parent
Re: (Score:1)
Re: (Score:2)
In this case, it's done via a customer selecting a URL, so it's up to the customer to decide what they want and we don't have to.
A better example would be with Java:
In regular Perl (no modules), it sometimes gets mistakenly rewritten as this:
Re: (Score:1)
Look at the method names. Do they really focus on what the methods do? Where is the axis of duplication? (hint: group by)
Re: (Score:2)
This was a tiny example and merely a first-pass refactor. If you look at the actual code I checked in, you'll see it's much cleaner.
Re: (Score:1)
Re: (Score:1)