Re^4: Tips for managing Perl projects?

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)}

Comment on Re^4: Tips for managing Perl projects?

Replies are listed 'Best First'.
Re^5: Tips for managing Perl projects? by hsmyers (Canon) on Dec 16, 2004 at 20:26 UTC
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]