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]

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

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]

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

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]

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

I find the second way totally unreadable.

I don't know whether you are in the minority or not but that's the way perltidy does it by default.

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