in reply to Re^2: printing a scalar as an array
in thread printing a scalar as an array

Using the stricture adds, uhm, exactly nothing at all to the above program. It just increases the size of the program text. As for adding -l, I tend to only do that for only liners - with normal programs, you just want to use 'print' without newlines often enough to make it a nuisance (it's still possible by using printf though). I disagree with the remark in update2 though. "Just calling the script using 'perl -l'" is a major PITA. You want to call program by just typing their file names, having to remember which interpreter they need is hard - and it's even harder to remember which program needs which command line options! Not to mention that that will make debugging even harder than having -l mentioned in the she-bang line - that's easier to spot than the -l enforced on the program from the outside.

However, I only write this node because of something else. What's with the quotes around $_ in the print statement? If you're going to nag about (pointless in this case) missing "use strict" statements, and whether or not to use -l vs. a newline, you should at least get rid of the not needed quotes around the variable.

Replies are listed 'Best First'.
Re^4: printing a scalar as an array
by RazorbladeBidet (Friar) on Feb 23, 2005 at 14:01 UTC
    "use strict" is not an option - it's a way of life!

    I would much rather see nagging (if I have to see nagging) about use strict than quotes around a $_ which will not add any overhead (?)

    Update: As for the 'perl -l' - I would lean away from that, but I have no real reasons I could back up. Why not just ($\="\n") ?
    --------------
    It's sad that a family can be torn apart by such a such a simple thing as a pack of wild dogs
[reply]
      Update: As for the 'perl -l' - I would lean away from that, but I have no real reasons I could back up. Why not just ($\="\n") ?

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

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

      [download]
      in some module buried three layers deep in your application infrastructure, just so you can write 
      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.

      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.

[reply]
[d/l]
[select]
        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
[reply]
[d/l]
      It's not the overhead. It's a bad habit. And eventually, it will bity you. People that tend to pointlessly quote scalars (and you see it happening not just with print, but with other function calls as well), will also quote them when the scalars happen to be refs. Oops. That's to reason to "nag" about use of quotes.

      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]
      (although you won't be able to print to a filehandle that way).
[reply]
[d/l]
[select]
        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
[reply]
[d/l]

In Section Seekers of Perl Wisdom