in reply to On bad habits

> 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

Replies are listed 'Best First'.
Re^2: On bad habits
by diotalevi (Canon) on Jun 21, 2005 at 15:38 UTC

    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.

      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.


      All that is gold does not glitter...
        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...
Re^2: On bad habits
by Xenograg (Scribe) on Jun 21, 2005 at 16:37 UTC
    If I am going to use newline frequently, I create a constant for it.
    use constant NEWLINE => "\n"; print $foobar . NEWLINE;
    --- The harder I work, the luckier I get.

      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. ;)


      (the triplet paradiddle with high-hat)
        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.


        • another intruder with the mooring in the heart of the Perl

        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; }

        I am obviously in the explicit-declaration faction.

        ++jeffa thanks for another WTDI. :)

        --- The harder I work, the luckier I get.

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