With respect to Perl::Tidy, it is quite obvious that a tidy file is one that has gone through perltidy and which does not change if reformatted again.
$ perltidy tidy_file.pl
$ diff tidy_file.pl tidy_file.pl.tdy
# zero, no difference
But Perl::Tidy is a work in progress which is constantly improving. And improving means changing. Those changes may include the fixes of some behaviors considered non-ideal or even flawed. So tidy files under a Perl::Tidy version may not be tidy under another version. So this concept is a little fragile (or needs a more precise wording).
Even Test::PerlTidy (which intends to capture that tidy-ness concept in the form of an automated test) was caught by this detail, since a new release of Perl::Tidy got out. Edmund von der Burg and me are working on a reasonable approach to this issue. Wait for a new release of Test-PerlTidy soon.
Universal problem (Score:1)
Any test where you can achieve a perfect score on a subjective metric is destined to cause "not my fault" failures in the future
isa(Perl::Tidy, Silly) (Score:1)
Re: (Score:1)
I also believe that claiming a tidy file (as per Perl::Tidy) is more human readable is a too presumptuous statement. Sometimes perltidy bugs me too because I cannot make it fit exactly with my mental model of desirable code layout. But one thing it achieves: an automatic/objective way to determine a layout, cleaning gratuitous difference on code styles and fixing details like: avoiding tabs, enforcing cuddled elses everywhere, etc. And this is a good thing for large codebases, meant to be worked out by man