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."
| [reply] |
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] |
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.";
| [reply] |
