Perltidy is great for managing the appearance of one's code, but it doesn't begin to address the management of an entire project.

Then it's clear you've never watched endless discussions of where to put the damn curly braces during peer review. I would repeat the admonition, get perltidy, use it.

--hsm

"Never try to teach a pig to sing...it wastes your time and it annoys the pig."

I've obviously not been clear. I'm not saying perltidy is a bad idea -- quite the opposite, in fact. However, there are two things I'd like to point out.

First, any decent manager will quash "style" discussions during review: if they can't be stopped, then a standard code format can be instituted (or threatened). With a small devel team working on in-house operations, I'm loathe to require a coding style -- most projects will be single-developer.

Second, while perltidy would solve most code style differences, that is such a tiny part of the overall issue. Perltidy address code style only.

radiantmatrix
require General::Disclaimer;
s//2fde04abe76c036c9074586c1/; while(m/(.)/g){print substr(' ,JPacehklnorstu',hex($1),1)}

it doesn't begin to address the management of an entire project.

Uhm... of course not. I think most people might realize that I wasn't trying to address the management of an entire project in my four word reply. I was providing a single "tip"... nothing more.

-sauoq
"My two cents aren't worth a dime.";