I've not encountered a script that assessed style, but there is perltidy that will reformat according to a configurable set of rules. I wouldn't be too hard to wrap that with another script that tidied the input file then did a diff between the input and the output and made some assessment of the changes.

Though its probably simpler to insist that all code is maintained in the code repository in some standardized style (defined in terms of a Pertidy configuration for example).

That way, people who prefer, or are accustomed to a different style to the 'house style', can set their editor to use perltidy to reformat the house style to their own preferences when it loads a script and back to the house style when it saves. That way, nobody finds themselves slowed down and driven crazy because they have to keep manually re-editing the stuff they naturally type in one way, but that the house style requires in another.

This won't take care of everything on the OP's 32 point list, but then, as the thread shows, many of those points are controversial to say the least.

Personally, I find some of them bewildering. Not using $_ when appropriate is a little like forcing me to say: Mister George William? Bush Esquire, currently of sixteen hundred Pennsylvania Avenue, Washington, District of Columbia, United States of America. each time instead of "The US president". It maybe (or may not in this case, I'm not sure of all the details:) be more accurate, but boy, is is ever long-winded.

In the same way that anyone in the US has a pretty good idea what you mean when you say "The President", (though you may have to say "The US president" outside of the US), so it is with $_. Anyone with more than a passing familarity with Perl, will, in most instances recognise the meaning and value of a given use of $_ in a given context. Of course it can be abused, but so can a long variable name.

The typical notion of obfuscation is to reduce all the variable names to single chars. Much more effective is to use meduim length, descriptive names that are apparently meaningful in the given context, but just not used for the purpose they apparently serve.

• A variable called $loop_counter that actually serves as a constant for determining loop termination.
• A package global array called @temp that is actually used to pass data between independant calls to the methods, but who's content varies depending on which method was called last. (Real life example!)
• Subs called max() and min() that have the test conditions inadvertantly reversed. (One of my own:()
• A sub called ValidateInput() that starts out checking that input is numeric but ends up with a mass of logic for reading the input from various sources and building data structures from it. Another real situation I've encountered. (I wasn't the author this time.)

In the end, no amount of automation is going to detect, never mind rectify stuff like this.