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)}
| [reply] |
Your points are good. I've simplified my life by forclosing the issue---first project meeting, a formatter is mandated by executive fiat (mine) and never there after becomes an issue. You are quite correct in saying this is a tiny part, but then so are most irratants!
--hsm
"Never try to teach a pig to sing...it wastes your time and it annoys the pig."
| [reply] |