|Problems? Is your data what you think it is?|
I don't think this is a technical problem, or one that we'll solve with technology. It's a people problem. If you already have a bad situation, an automated tool isn't going to make it any better. I know you said this with the smiley face attached, but the problem isn't the language. By the time people get to quibbling about the actual code, they've already passed through most of other problems that allowed that to happen.
The best thing that people can do, I think, is work together. Programmers (or any other sort of worker) aren't veal calves to shove in cubicles. Although I won't go as far as recommending company retreats, people in the same organization should know each other, and know what other people are doing.
For managers, this means actually inspecting the work of their subordinates and tracking its progress. You don't do that with an automated tool. You actually have to look at the code, and you have to think about it in terms of everything else. It's not just the syntax that's important, but how it relates to everything else. What does the code let you do? More importantly, what does it keep you from doing? What decisions does the code make for you if you allow a certain design?
A good manager could use Perl::Critic, but tools don't and won't make good managers.
brian d foy <firstname.lastname@example.org>
Subscribe to The Perl Review