|P is for Practical|
I can come up with many reasons why you want to put time and effort into this!
For the purpose of the this discussion, let us assume I have taken over the module the OP wrote years ago, and for good reason, he/she put up for grabs (no more interest in Perl, no more access to required resources, left life, ...).
Now, for obvious reasons, I do *not* like the style/layout of the code this module was (consistently) written in, and - also for this discussion - the module has thousands of lines of code.
I think that code needs to be easy to *read* in order to be able to maintain it properly, so next to *consistent* indentation and styling, it needs to be beautiful and that is where perltidy drops in place.
Whatever style the module's code was written in, I run perltidy with *my* preferences, and suddenly all the code looks beautiful, so I can understand it. Next step is to edit all the code by hand and make the last mis-formats match my own style. As no software is perfect, there will be parts that are not formatted according taste.
By browsing/editing the codebase, I now get acquainted by the code's structure and main parts and I can start focusing on open issues and bugs.
By having a .perltidyrc file that formats the code to as close as possible what you think is best (and we will not agree there), you will save yourself a lot of time later on.
Enjoy, Have FUN! H.Merijn
In reply to Re^2: Why is perltidy using indent-columns instead of continuation-indentation when breaking up a long if-line?