in reply to Re: CPAN's perltidy to the rescue! (not for 'standards')
in thread CPAN's perltidy to the rescue!

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

... 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; } };

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

Replies are listed 'Best First'.
Re^3: CPAN's perltidy to the rescue! (not for 'standards')
by mr.nick (Chaplain) on Aug 27, 2012 at 19:32 UTC
    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' ]; #>>>

    mr.nick ...