For the same reason that you shouldn't say something like:

*CORE::log = sub {
    # Your logging code here
}
[download]

do_some_operation( @args )
    or log( "some_operation() failed with @args!" );
[download]

Can you see the problem? What about if I wanted to add some mathematical functionality to this application that required the use of logarithms and the log() builtin function?

The point is that you never want to violate the "Principle of Least Surprise". There are many, many community expectations in terms of how code will behave. One is that print() does not append a newline. If it suddenly starts doing so, I know I'd get very confused and spend a lot of time trying to figure out why. Modifying $\ or adding -l to the commandline is a very quiet way of making a very large global change that will confuse people who try and read your code, especially after you no longer work there.

Remember - your code belongs to your employer and you have a responsability to make sure that maintenance of said code is as cost-efficient as possible.

Duly noted.

How about then:


local $\="\n";
[download]



I understand what you are saying about the PoLS, however. I do not intend to go changing to use that, just seeing how that applies to your point above.
--------------
It's sad that a family can be torn apart by such a such a simple thing as a pack of wild dogs

As for not using $\ = "\n", to do it right, you'd have to do it each time before a print, and do it localized, or some other part of the program might act unexpectedly.

If you don't want to type the "\n", use Perl6::Say (or whatever it is called), or use something like:

sub printnl {print @_, "\n"}
[download]

Hmm...



use strict;
my $a = 1;
my $b = \$a;
print $b, "\n";
print "$b\n";
[download]



both print the same thing - why is that bad? I'm really just curious.

as for $\="\n", I agree, localized is the way to go, but you don't have to do it before each print (unless, of course, your localized version goes out of scope).

but I still stand by "use strict" being more important than removing unnecessary double-quotes

I hope this argument isn't getting too petty :)
--------------
It's sad that a family can be torn apart by such a such a simple thing as a pack of wild dogs

As I said, people tend to quote scalar not just with print. Consider this:

#!/usr/bin/perl

use strict;
use warnings;

sub gimme_first ($) {$_[0]->[0]}

my $a = [1, 2, 3];

print gimme_first $a, "\n";
print gimme_first "$a", "\n";
[download]

as for $\="\n", I agree, localized is the way to go, but you don't have to do it before each print (unless, of course, your localized version goes out of scope).

Well, that would be wrong. In the following code:

{   local $\ = "\n";
    print "whatever";
    imported_subroutine ();
    print "something else";
}
[download]

the problem is that $\ doesn't go out of scope. Even when imported_subroutine is run, the modified $\ is still in scope.

And I still stand by that if you're going to nag about a "use strict" missing from a code fragment, I will nag about anything you write.

(Trust me to start a row)

IMHO you're both right. Using strict solves so many problems that many questions would never be asked if the poster was using strict in the first place. Witness the number of SOPWs that get half a dozen answers saying nothing but

use strict;
use warnings
[download]

Its probably always worth putting it on code fragments that perform a complete task such as this.

As to the quoted eval, on this occasion that was left over from a previous attempt to solve the problem, but generally speaking its a bad habit of mine that I need to get out of. Its a bit like one of those words you habitually mispell even though if you stop to think, you know perfectly well what it should be.

VGhpcyBtZXNzYWdlIGludGVudGlvbmFsbHkgcG9pbnRsZXNz

Next, you two are going to start arguing cuddling elses or vi vs. emacs or any number of other equally pointless things. I think you two are in violent agreement.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.