use constant FOO => "BAR";

print << "BAZ"
@{[ FOO ]}
BAZ
[download]

I particularly enjoy this "poor man's templating" technique for very short CGI scripts where I don't want to load Template Toolkit II or some such, but still want to enjoy the benefits of separating application logic from display formatting. It can get tricky real quick like if you want to quote stuff inside the deref block though, so it doesn't scale very well. But that's okay - it keeps me from being falsely lazy when such a script happens to grow. :)

Of course, that's not real a solution for simple doublequotes, as

Makeshifts last the longest.

Yes, you can do that if you really want to. Keep in mind, though, that will result in the sub being called in list context. If you want to force scalar context you will have to do so explicitly which makes an ugly construct even more unwieldy.

-sauoq
"My two cents aren't worth a dime.";

Good catch. You could force scalar context by simply using ${\( $q->param('real_name') )} though - I just dislike this one and don't use it unless necessary because I find it way uglier than an arrayderef.

Makeshifts last the longest.

As for the example, I'd rather use a slice rather than mentioning the params array on every line. That would mimic the common argument-list idiom of my ($n1, $n2, $n3)= @_;. So that would be something like

my ($localname1, $ln2, $ln3)= @original{qw/name1 name2 name3/};
[download]

—John

Not everyone uses a glass TTY or emulates it with a fixed-width font.

No, but many of us do. It's the least common denominator. If you want your code to be maintainable regardless of the environment preferred by the maintainer, you really should keep it in mind.

Even most of those who don't constrain themselves to a proper 80 character line use fixed-width fonts. Even most lame editors that come embedded in the plethora of available "integrated development environments" at least default to a fixed width font. How many nodes here are considered because code tags weren't used and the result is almost unreadable even when BR tags are inserted? What font do you use?

I strongly stand by my statement that the assignment operators should be lined up. It doesn't take much more work (even when you have to change a bunch of them) and it is worth it to give your code a polished look.

I think that the code

my $foo = 'bar'; 
my $bazqux = 42; 
my $quux = "$bazqux ${foo}s"; 
my $money = 'gold'; 
my $total_fortune = $quux . "of $money\n";
[download]

is simply more readable as

my $foo           = 'bar'; 
my $bazqux        = 42; 
my $quux          = "$bazqux ${foo}s"; 
my $money         = 'gold'; 
my $total_fortune = $quux . "of $money\n";
[download]

and if you actually disagree, well, you are welcome to your opinion on the matter (right up until the day you do any work for me, that is.)

As for the example, I'd rather use a slice rather than mentioning the params array on every line.

In the example, the multiple assignments were separate calls to the param() method of the CGI object called $q, not assignment to several elements at different keys in the same hash. If it was the latter, I probably wouldn't recommend assigning to scalars at all. If it really made sense though, I'd be inclined to agree that a hash slice would be the way to go.... maybe. Even that might be a lot less maintainable if there were many variables. Consider:

my ($foo, $bar,..., $baz,... $qux) = @hash{'abc', 'def',..., 'pqr',...
+ 'yz'};
[download]

versus

my $foo = $hash{abc}; 
my $bar = $hash{def};
.
.
. 
my $baz = $hash{pqr}; 
.
.
.
my qux = $hash{yz};
[download]

The more verbose method neatly puts each variable on the same line as its hash element. If you had to change the assignment to $baz in the former of those two methods, you'd find yourself counting keys in your slice to find the one it matched with. That's a pretty ugly situation.

I don't know if the accessor function has something similar. That is, if passed multiple arguments will it return a list as well?

No. Calling it with multiple arguments, as in

$q->param('foo','bar','baz')
[download]

will result in the parameter 'foo' being assigned an array with the values 'bar' and 'baz' in it. It's the same as calling it as

$q->param(-name => 'foo', -values => ['bar', 'baz'])
[download]

-sauoq
"My two cents aren't worth a dime.";

is simply more readable as...

I find the second way totally unreadable. I can't see the left side and right side at the same time. I read code like I read sentences, not like a table. I won't line up this paragraph with all the subjects on the left, verbs in their own column, and predicates justified to the right. The gap between the "my $foo" and the RHS is bigger than the left hand side! That makes me think of the break as a significant thing in itself.

Remember the book "Code Complete"? I think there was a discussion of that in there. I remember discussing it at length on another forum a few years ago.

What font do I use? In the programming editor, it's Veranda 8. I think that's what it came set to. I seem to have lost my custom settings (the comments are blue; I had set them to green).

Calling with multiple arguments...

Perhaps this is something that authors should keep in mind. How often do we have hash-like bags of named things, as opposed to a known structure? The "param" really is like parameters; just known at a different level.