I agree. I think perltidy is great. (That's perltidy for the search-impared).

I feel more productive when I keep my code formatted reasonably well as I'm working with it. But before significant commits (especially ones that will get merged back into a more stable branch), I usually pass it through perltidy first (This works out best if everyone plays by the same rules, or else your 'git diff' becomes a log of all the changes perltidy made, and the potential for merge rejects increases). Often when I compare what I thought was reasonable formatting with what perltidy comes up with, I have to agree with its assessment. But there's a consistent issue that always bugged me. It has to do with how it chooses to indent a qw// list (by default). Here's a contrived example:

# How I like to see it.
my @stuff = qw(  some  big     list  
                 of    items   that 
                 spans several rows  );


# How perltidy likes to see it.
my @stuff = qw(  some  big     list
  of    items   that
  spans several rows  );
[download]

Finally it annoyed me enough that I dug into the docs and discovered the -ntqw command line switch. Much happier now. :)

That's the sort of thing nobody can agree on; here's how I like to see it:

my @stuff = qw/
    some  big     list
    of    items   that
    spans several rows
/;
[download]

It's really awesome that perltidy lets you customize all that!

I honestly believe that mandated style guides for coding are a waste of time. It's so easy to just run all code through perltidy (or the like) and automatically format every line up to a common standard. No reason to chastise coders for their evil non standard ways, or hoist meetings and style reviews on an otherwise productive day. Just let programmers do their thing and then perltidy it before sharing.

If the world spent more time using pertidy and less time endlessly arguing coding standards, we'd all get more work done.

reuzam, isn't it amazing how much energy a simple thank you can create - LOL!

I also am a strong proponent of using perltidy. I have been cranking perl code since version 2.0 came out - I guess that makes me a dinosaur. Over the years, I have used a whole bunch of different development environments, tools and appraoches to perl and other languages. Without exception, I have returned to the following kit

• vim/gvim
• perl-support for vim
• perltidy
• perlcritic

I am not saying categorically that this is the best approach in the world, but it is best for me. As a younger code wrangler, I used to get very carried away with how code should be structured and formatted. I thought my ideas were the best, and often they were in the case in which we were working. I felt like my creativity was in how the code was structured and that code should be presented in its absolute best light. As I age, I come to realize that the best way to present good code is in the end result. All the rest is just hubris.

Results to me mean:

• The delivered solution meets/exceeds users/consumers needs
• The code is structured in a way that easily understood and adequately commented

While perltidy can't directly help with the former, it can be a great tool with the latter. perl-support in vim does a great job with syntax highlighting and helping me insure that all opening {[( are closed. While developing, I inherently tab here and there and do a bit of formatting; however, I don't sweat the formatting. Before each and every save, I \rs (compile the code to make sure my syntax is clean) and \ry (run perltidy from within vim) and then save.

I love that I don't spend practically "no" time worrying about formatting code. While I don't necessarily love every little thing about perltidy ( like the earlier comment on qw formatting ), overall it is great. I can readily see the structure and the flow of code -- it makes my visual cortex happy!

And one last thought, if you are arguiing about how code format interferes with your creativity, stop, get a drink, maybe an adult one, and reassess what creativity is and your ability to be creative;)

lbe

WHOOOSH

I guess I'm the only one who has had the joy of significant headaches from over-use of perltidy. But I'm even more shocked at how popular it appears to be to subject yourself to mindless enforcers of standards. I feel like Will Smith in the I Robot movie.

I can certainly see the value in using perltidy for one-time conversion of some code from "their ugly (extreme) style" to "something much better".

But I just don't have a huge problem dealing with code written using any of a large number of reasonable, popular, similar, conservative styles.

And I much prefer allowing programmers to innovate and come up with even better ways of coding than happen to be already coded into perltidy. Setting your coding standards in stone is one of the things that I find is the wrong way to do coding standards. Nobody learns. Nobody grows.

I also actually have to deal with merges and code reviews. And I'm pretty sure perltidy can't reformat a diff or a merge conflict to the personal style of whoever, especially integrated into my review tool or any of my merge tools.

If perltidy were fully powerful and error-free, then I could almost tolerate using it as a must-always-be-used translation layer. For example, if we were talking about converting between utf-8 and utf-16, then converting back and forth all of the time, even without review by a human, could be a reasonable work flow.

But I have innovated coding constructs and seen others do it where perltidy just couldn't correctly cope with the result. And I've seen people using perltidy and deciding to just "never do $technique because that sucks with perltidy". Heck, I've even developed just innovations in indentation that finally made a huge improvement in clarity that perltidy can't help but just destroy.

If you can't deal with some 'else's or braces being cuddled and some not to the point of endlessly arguing and trying to enforce some "one true style", then I think you should work on your personal problems instead of looking for a tool.

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.

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

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        

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.

No matter what the adopted “standard” might be for any particular shop, it is nevertheless true that we are visual creatures whose eyes are strongly tuned to the presence of “order.”   We can fairly easily adapt to any sort of consistent “orderliness” that we encounter ... as long as we ultimately find consistent visual order of some kind (any kind) to be present.   When that happens, we start to be able to notice that “something doesn’t look quite right here” because it is different.   Given the time that we literally spend staring-at code, looking for errors and inconsistencies, visual order and orderliness has a very recognizable bottom-line ($$!) value.

As someone who has (a) written COBOL for a living, and (b) suffered through the same injustices that have been described ...

I personally believe that it does not really matter much what “the standard” is, so long as there is “a standard.”   In other words, the ultimate goal is to be able to leverage our visual cortex.   This is the part of our brain that is designed to recognize the Tiger in the underbrush.   It is extraordinarily tuned to differences.   It is also subliminal, in the sense that you do not necessarily have time to generate “conscious thought” to keep you out of the jaws of that tiger.   Hence, you might sense something even if you can’t put your finger on it ... and that is very important.

Indentation, CaMeL Case vs. what-have-you ... I truly think that it does not matter what “the baseline” is, so long as it is applied consistently enough that “differences” stand out.   Sometimes, we feel that something is not-quite right, but we can’t quite put our finger on it . . .

We want to be able to exploit that innate ability of our brains.   And we are able to do that, through the use of tools that create visual-consistency.