[sf-perl] Whack your Perl code
fred at redhotpenguin.com
Thu Apr 12 18:54:13 PDT 2012
On Thu, Apr 12, 2012 at 6:07 PM, matthew wickline <matthew at wickline.org> wrote:
>> Refactoring without business goals can cause
>> problems more often than not I've found.
> and then there are the cases where some very complicated piece of code
> has been given the "minimal working edit" so often because nobody
> wants to risk a refactor when not strictly needed. Eventually you can
> end up with subroutines thousands of lines long with loops/conditions
> up to a dozen layers deep. I've seen them. I've heard about them from
> others. There is never a task which in and of itself warrants
> re-writting such behemoths. Eventually you see enough buggy
> implementations from folks failing to grok the giant sub that you
> decide that there is business value in re-writting it for the sake of
> making it easier to maintain and modify in the future.
I've written them myself, it happens sometimes even when I strive to
keep things simple. I ran whack.pl on some of my code and it picked
those subroutines out accurately.
I agree there's business value in refactoring code like that. My
previous email may have come across as anti-refactoring
unintentionally, but I was attempting to convey that I've found it
useful to define my goals when refactoring code. I've found with my
own code that going in and 'cleaning up' things (not tidy or critic
compliance efforts) doesn't always add value to it.
> If you're not working in code old enough, of sufficient scope, and/or
> worked on by folks with sufficient range of experience to have these
> sorts of problems, then consider yourself blessed that you don't need
> to whack it :)
More information about the SanFrancisco-pm