I disagree about your comments on the title of PBP.
...
the benefits of its existence far outweigh the negatives (including the name).

Don't you see a contradiction here? So far you have defended the book, and I agree. You did not, though, explain why you disagree with me saying the title is bad - you just say it doesn't matter.

Well, for me, it matters.

But really, given the choice between PBP and an in-house standard cobbled together by said incompetent management which would you prefer!?

What choice is that? Given the choice between a burger from <insert-junk-food-company-here> and your own fried shoe soles without salad and no onion, what would you prefer?

I would see this most excellent book from Damian Comway as a style guide or vade mecum to gain perl insight and develop a good inhouse coding standard, rather than having the book as a whole imposed as such, without reading it, and merely because of its title.

Which means: if anybody, including the PHB, after reading it gets enlightened and shouts "hey, these are really jolly well best perl practices!" and goes to introduce a subset or all as standard, that's perfectly fine.
It is not ok if someone comes and says "here, have Perl Best Practices. It's standard now." - "Why?" - "Because they are. Can't read the title?"

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Does the title matter? I think given any good to great choice that it doesn't (while I'm here I'll throw out "Writing Perl with Style"). Why? Because the people that blindly follow it and the people that force it on others without due consideration would do so anyway!

Okay, so maybe the title does matter a little bit. You are concerned about management using the title to justify using it as a coding standard. But what about the reverse? Developers could just as easily use the title to help finally get a coding standard in place.

As for choice, I think the better analogy is a gourmet hamburger from say Blueberry Hill here in St. Louis vs. one from a fast food chain, but that's dependant on one's opinion of the book.

Lets face it, a book like PBP has been long overdue. That coupled with the high quality of it leads me to believe we will not see something similar to it for some time. Throw in the input from several members of the Perl community and, well, quite frankly, I think the title fits.

and I don't see that as a bad practice. Works like expected and is documented. The alternative would be to shove the result explicitly through three other subs:

$thingy -> foo (1,2) -> to_output_channel; 
$string = $thingy -> foo (1,2) -> as_string; 
@lines = $thingy -> foo (1,2) -> as_list;
[download]

which gains me what exactly?

1. explicit clarity of intent
2. 3 parameterizable output methods
3. 3 methods which can be re-used or overloaded as needed
4. The ability to call all 3 output methods, none or any combination simply by mixing/matching method calls.

Should I avoid localtime and roll my own?

1. explicit clarity of intent

I have that on the LHS.

2. 3 parameterizable output methods
3. 3 methods which can be re-used or overloaded as needed
4. The ability to call all 3 output methods, none or any combination simply by mixing/matching method calls.

No call for those, since that doesn't gain me anything.

You missed my point. Context awareness is a key concept of Perl. Deprecating context awareness with regard to subroutine return is tantamount to crippling the language.

Try Date::localtime

No such module... ;-)

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}