The thread Declaring and checking content of variables with consecutive names and especially the answer Re: Declaring and checking content of variables with consecutive names triggered this meditation.

There is nothing special about this thread or this answer, it's just one of those FAQs (in this case "How can I get variable variable names"). People explain how to do the job properly, and some other people can't resist showing that there is a way how to force perl into using the stupid variant. I vagely remember threads where people tried to find even more stupid ways to "solve" a cleanly solveable problem.

Yes, we can force perl into doing the most stupid things. Yes, it's cool to know how to mess with the inner workings of perl. But no, we should not show beginners the most dirty ways first. Not even with warnings not to use the dirty ways in production code. "Just do as I say, don't do as I do" is no good motto, not for teaching beginners.

Why? Because there are lots of beginners out there, who either don't have time to or are unwilling to learn how to use perl. They just want fast results, they don't care about maintainability or improving their skills. Imagine what happens when they get ten answers linking to FAQs, HOWTOs, documentation, or showing examples of the right way, but require a little bit of thinking; and one or two answers showing how to abuse perl into the way they are currently thinking.

"There is nothing humans would not do to avoid thinking."
-- Found on a pinboard in a computer laboratory in my univerity

This way, bad practices propagate, resulting in crappy perl scripts.

Let's make it hard for the unwilling and the people in a hurry to find bad code, bad examples. Posting sane examples is good, improving a code example posted is even better.

But what about golf?

Perl golf is fun, true. Replacing pages and pages of code with 20 characters of "line noise" with the same result is deeply impressive. But do we have to show our golf skills in beginner threads? I don't think so. Create a new thread, link to the beginner's thread, and name it "Golf Challenge". Or at least start a golf posting by explaining that this is not a real answer, but a golf challenge for the experts.

Are one-liners bad?

(A meditation in a meditation)

It depends. Short one-liners for one-time use are ok. But for anything more complex than one or two, maybe three explicit instructions (not counting the implicit loops in perl -p and perl -n) should be in a script. And if the one-liner is to be reused, it should instead be a script, too.

Why?

• One-liners require that you remember quite complex "line noise". So you very likely store them in a file. What's the difference to using a real script? It's just harder to use, as you need to copy-and-paste.
• Quoting rules differ with different shells (and different operating systems), so you need to adapt the one-liners, especially the arguments to perl -e and perl -E, to the shell currently in use. Scripts don't have this problem.
• Scripts can have nice names. cleanup-foo is easier to remember, easier to type, and shows the intention more clearly than perl + 10 perl command line options + -e plus 80 characters of "line noise" in quotes differing from shell to shell.

Alexander