"We did some really stupid stuff when I was writing COBOL. If we'd had something like perltidy, we could have done this really stupid stuff much, much more efficiently. We had to stop doing it because it was so expensive. If we'd had perltidy, we could have afforded to keep doing that stupid stuff much, much longer."

You make a compelling case. :)

Don't misinterpret my previous node. I don't discount that perltidy can be a huge improvement. Using perltidy as part of a two-way "let me keep my picky style and I bet you won't even notice" work flow in a group programming project strikes me as a big improvement rather like having a job in water treatment and discovering how things are tons better now that you've discovered a new tool... a snorkel for all of the times you have to swim through the sewage. Meanwhile, I refuse to keep the swimming as part of my job description and just see no benefit to having a snorkel to make it less terrible.

More recently I had a patch rejected from a project simply because it didn't pass an automated style checker (the code worked and tested as advertised).

You made a patch and couldn't be bothered to stick with the style already evident in the code? Yeah, you should certainly try to get over that problem.

It sounds like that project is doing some things rather stupidly. If one wants an inflexible robot reviewing patch submissions, then it is pretty stupid to not put that robot in the beginning of the submission process so that somebody submitting a patch knows even before they have finished the submission process that their patch violated the robot's rules and why. Of course, I'd also allow the submitter to choose to cancel or force the submission because inflexible robots often have quite lousy judgement (except in the case of very simple, clear-cut, not-error-prone, and easy-to-honor requirements).

And if one hasn't done that (yet), then one should make the whole funnel for getting to the patch submission process nearly force the submitter to realize that a "style test" will be applied and make it as trivial as possible for potential contributors to access the test tool (with all of the right settings).

In the case of a submission that the robot doesn't like, I (personally) wouldn't honor the robot's "reject" conclusion for a style violation unless 1) bringing the patched code into conformance was a pretty trivial operation and so the failure was a result of submitter ignorance and/or laziness (and ignorance often implies laziness in these situations) and so it is worth waiting a while to see if the submitter will make the trivial fixes and resubmit. Or 2) the violation was severe and so the work to "fix" the style is more than is warranted by the value of the patch.

(it's configurable right?)

Ah, so you are speaking from strong personal experience on this point.

I think it would be counter productive to make other contributors jump through my style hoops.

Sure, when it is done badly (as it seems was done to you). But perhaps you shouldn't let the one experience dominate your thinking on the matter.

I like to see other people's style and to discuss what benefits they receive and to learn. I also find it is very good to not hide from other people's styles because it helps to prevent me from becoming overly attached to personal style proclivities.

I find that last part is really valuable. I can even look at Perl code I wrote over a decade ago and hardly even notice the minor style choices that I've given up since then.