I was working on an open-source Perl application recently, paying particular attention to one of the modules within. Unfortunately, the formatting left a little to be desired, with a highly idiosyncratic and inconsistent level of indentation and use of bracketing.

Not one to be put off by this, I quickly installed perltidy, and ran it against the file.

perltidy Package.pm

After a few seconds, this created a file in the same directory called Perltidy.pm.tdy, with various changes made to the formatting.

The manpage showed it had a huge number of options, allowing one to choose from various different styles. For the most part, I was happy with the defaults. Although when coding C or LPC I prefer 3-space indents rather than two, Perl’s frequent use of block early-returns and flow modifiers like last and next means it makes sense to outdent them slightly. It’s easier to read such outdents when using 4-space indents.

My chosen options, in the end, looked like this:
-b – inplace tidying, saves the original file to .bak, rather than creating a newly-styled file with .tdy extension.
-ce – cuddle elses – the default places else on a new line after the previous closing brace, which allows closing-side comments, but disrupts the flow of the if statement.
-syn – do a syntax check with Perl while tidying
-okw – outdent keywords like next and last
-csc – enable closing-side comments – comments after the closing brace of a long sub or conditional statement.
-csci=12 – minimum number of lines in a block to add closing-side comment – the default is 6.

perltidy -b -ce -syn -okw -csc -csci=12 Package.pm

The problem now is how to check my changes back in without seriously upsetting the package maintainer; almost every line in the package has been changed, so the patch will be practically impossible for him to verify. Oh, well.