Re: On bad habits

[cosimo]

> Excessive use of double quote interpolation - I'm really
> doing myself no favours with print "$variable"; but I use
> print "$variable\n"; very heavily so the " gets to be a
> reflex, even where I'm not using \n.

I must admit I also have this "weakness", although I happen to prefer:

    print $var, "\n";
    # but...
    print "$var\n" for @list;
    # or...
    print($var, "\n") for @list;

> Excessive use of foreach, where join or map would be preferable

You can eliminate this bad habit just by using for instead of foreach :-)

> Excessive use of eval. I've just about cured myself of
> that, since I found out how slow it is.

I don't think eval is slow. Eval'ing a string is slow, because IIRC it spawns a "new" interpreter, but eval'ing a block is ok.

> Using / as a regex separator, when the regex would be
> clearer with an alternative.

Yes, I'm also with you on this one, though at times I use the pipe char (|) instead of /.

> Using quoted strings where print <<END_BLOCK
> would make it clearer.

I'm with you here. Sometimes I don't "feel" using here docs, even if <<'       END_OF_TEXT' allows for clean indented blocks.

Just my € 0.02

[diotalevi]

eval STRING does not spawn a new interpreter. It makes a call to the compiler to parse and compile the string. Then it executes it and throws away the newly compiled code.

Here-docs are a cause of a class of error you can only avoid by avoiding here-docs. Lest that sound dumb to you, try adding a space to the end of your here-doc tag in the <<TAG start or in the TAG end. Both are usually invisible and both will cause your script's parsing to be completely awry. They're just a great way to shoot yourself in the foot.

[Aragorn]

This is where your editor can help. Emacs' cperl-mode can display trailing whitespace. For example:

print <<"EOT";
This is
a piece
of text.
EOT_

The underscore after EOT indicates a trailing space which can help a lot in this case.

Arjen

[Akhasha]

I avoid here-docs because cperl-mode's syntax hilighting and indentation seems to be often thrown by it. Maybe there's a workaround I'm not aware of...

[Xenograg]

If I am going to use newline frequently, I create a constant for it.

use constant NEWLINE => "\n";

print $foobar . NEWLINE;

[jeffa]

No thanks. :) If i am going to use a newline frequently, i add the -l (dash elle) run switch:

#!/usr/bin/perl -l

And then i don't need to worry about adding newlines. Uh oh ... what if i don't want to always print out a newline? Simple, just use printf.

Work smart ... not hard. ;)

[grinder]

what if i don't want to always print out a newline? Simple, just use printf.

For years, I have been sitting here, railing and fuming silently against the supposed "brokenness" of printf's disrespect for -l. It's something I'd always put aside as a non-orthogonal oddity of the language.

My anger blinded me to the possibility of using my opponent's strength to my own advantage -- a classic judo move.

Thank-you for letting me see the error of my ways.

jeffa++

[bart]

If i am going to use a newline frequently, i add the -l (dash elle) run switch

And if I want the effect locally, I set $\ (and optionally, $,) in a block, for example to print out a tab delimited text file:

{
    local($\, $,) = ("\n", "\t");
    print @fields;
}

[Xenograg]

I am obviously in the explicit-declaration faction.

++jeffa thanks for another WTDI. :)

[kaif]

Alternatively, remember that unless you changed it for slurp mode or whatnot, $/ is a newline.