I pretty much never use perltidy.

With enough command-line options, I can more or less get perltidy to respect my personal coding style. However, the problem is that it's not smart enough to realise when I'm deliberately disobeying my own conventions. For example, I don't want a deliberately compacted do{if/elsif/else} block, a la...

my $content = do {
    if (is_filehandle $f) { local $/ = <$f> }
    elsif (-f $f)         { local(@ARGV, $/) = $f; <> }
    else                  { LWP::UserAgent->new->get($f)->decoded_cont
+ent }
};
[download]

... to be expanded to my normal conventions of opening and closing braces on their own lines:

my $content = do
{
    if (is_filehandle $f)
    {
        local $/ = <$f>;
    }
    elsif (-f $f)
    {
        local(@ARGV, $/) = $f;
        <>;
    }
    else
    {
        LWP::UserAgent->new->get($f)->decoded_content;
    }
};
[download]

... even though the latter sticks to my "official" coding style to the letter.

I think coding styles need to be flexible enough to cope with exceptions when those exceptions make the code more readable.

I realize how old this node is, but as a big fan of perltidy AND someone who writes some specific stylings that perltidy can't grok, I did want to point out that you can tell perltidy not to touch specific blocks of code with:

#<<<
my $code = [ 'that',
             'you',
             'shouldnt',
             'touch'
           ];
#>>>
[download]

mr.nick ...

My last big corporate gig involving COBOL (many years ago now) jumped on board the 'standard code' bandwagon. The company paid dearly for a tool that defined every single aspect of COBOL code. Unlike perltidy, however, this tool didn't reformat code, it only scanned it, then spit out a long list of deviations followed by a grade. Many, many meetings were held to discuss 'what' should be considered standard code (which varied from department to department), followed by more meetings about how the standard was going to be enforced within the company, and even more meetings about how to deal with legacy code (which not surprisingly, was eventually excluded from the standards). Standards committees created and standards reviewers positions were created to ensure that all work met minimum standards. Code reviews stopped being about whether the code actually worked the way it was supposed to, and instead became reviews about how to fix it so that it passed the minimum standard grade. After several years of this the overhead fell in on itself and the 'standards' grading system was scrapped in favour of common sense code reviews. If there had been a 'COBOLTIDY' back in the day instead of some style standards grader, a whole heap of work could have been avoided. Then again, anything to do with COBOL seems to be encumbered with a certain amount of pointlessness.

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

What I like about (the idea of) perltidy is that even though it may not align with my personal coding style, it will at least bring everyone's style into a common melting pot, without enforcing it on anyone. So I as a coder am free to write in what ever form I'm comfortable with and pertidy can take care of making it readable to the rest of the population. I like to think my style is perfectly readable as is (or at least continually getting better with experience - I hope).

I'm considering running my personal pet projects through perltidy. Not because I necessarily believe in perltidy's definition of 'standard' (it's configurable right?), but if/when I start accepting code from other developers, I think I might like to have contributions automatically reformatted through perltidy. I think it would be counter productive to make other contributors jump through my style hoops.

Yikes! I'm flashbacking on COBOL. The heat must really be getting to me this week...

"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.

- tye        

Don't misinterpret my previous posts either. I didn't mean to suggest that perltidy is the end all. But I do suggest that using a tool like perltidy is a much better alternative than rigid style conformance. Being able to see other people's style and learning from it can be an unheard of luxury in many work environments (at least the majority I've been exposed to). You are indeed most fortunate.

My poorly described patch rejection example didn't help. The patch in question contained less than half a dozen lines of code, which (I thought) followed the flavour of the original. I don't even know what style guides were violated, just that the reason for the patch being dropped was that it didn't conform. My patch fixed a problem I was having with URLs generated while running the application behind a proxy. I am just a casual user of the project, contributing a fix that solved a problem for me that I thought would be useful to others, nothing more.

I can say with full confidence that I would be embarrassed to show anyone the Perl code I wrote over a decade ago :)

You make a lot of good points but the one I disagree with is...

You made a patch and couldn't be bothered to stick with the style already evident in the code?

If I'm a casual user of the code and I whip up something that works and is similar to the apparent style, then yeah, I can't be arsed to format it correctly for submission to your project (not at $WORK). Why should I spend hours to learn yet another set of coding standards to submit a 10 line patch just to satisfy some stupid robot? If an actual developer took a peek, he'd see exactly what the bug was... it's just silly to reject what might be a critical security fix just because some guy used tabs instead of 4 spaces.

I do understand, people submitting half-assed patches all the time is lame, but we should have a bit of patience with the random_guy@internet that actually bothered to submit a patch.

I'm a huge fan of perltidy. At work, I pushed us to institute a policy where all code is run through perltidy before being checked in. The reason isn't that I want to enforce my views or standards on code style, but because many of my coworkers either follow no consistent style, or because they use very odd styles that are rarely seen in Perl (a couple of them have more experience programming in other languages, and they write their Perl as if it were Java or C++).

Alternately, there's also a guy at work who likes to write code in a window that's 150 characters wide. As a result, he writes a ton of really long lined code. For those of us who do a lot of maintenance work on our code, frequently working in vi on a 80x24 console window, it's a huge pain to deal with.

Life is *much* better since that policy was put into place.

But, here's the thing. I use perltidy constantly even on my own code. It gives me the freedom to not worry about formatting when I'm writing or editing my code. If I wrap something in a new block, I'm not going to bother reindenting a bunch of code. I'm just going to run perltidy on it. Line up a list of things? Why waste the time? Same thing with lining up comments, and so many other things.

Remember, one of the keys to a good programmer is laziness. I love being able to write my code with a lazy style. perltidy cleans up after it, so I don't have to.