Nice. ++
I once planned to use perltidy to do something similar as part of CPANTS. However, it fell off the bottom of my TODO list. :-)
One of the planned features was to compare the input and output sources using several known styles. This would hopefully give sufficient credit to code that was using a consistent style even if it didn't conform to perltidy's default which is perlstyle. The intention was to provide an objective code metric. Whether, the metric would be useful or not is another debate.
One note, the system call should probably be something like the following for Unix systems:
system("perltidy $_") == 0
...
--
John.
| [reply]
[d/l] |
Unfortunately, this only counts discrepancy in lines. It's a sort of Levenshtein Distance of lines.
Typically, smart-indenting editors and perltidy can only approximate each other's code (since both are essentially trying to "parse" the syntax, and as we know, only perl can parse Perl). Emacs and perltidy can come close, but don't always agree. I tidy up some foreign code when I get it, then edit from there without re-tidying. So some level of disagreement is quite common.
For a better result, I'd like to see a patch to perltidy where it accumulates a "cost to fix" for each situation it wants to fix. Then you're not post-processing perltidy, but asking perltidy itself: how bad was this sloppy code, quantitatively?
I'd also like a minor mode in emacs where it occasionally executes (perl -c $filename) invisibly, then slightly tints the background of all the lines following the first error found (or better, though I think unsupported, is to tint the relevant fraction of the buffer's scrollbar). You could adjust this to do the same for perltidy... highlighting the first egregious tidy problem.
--
[ e d @ h a l l e y . c c ]
| [reply]
[d/l]
[select] |
