in reply to Re: Re: •Re: Find illegal ASCII characters
in thread Find illegal ASCII characters

I was going to answer something like that, but forgot all about it. In the meantime, I've read (once again) some parts of CGI.pm, and found these interesting regexes:

         $toencode =~ s{&}{&}gso;
         $toencode =~ s{<}{&lt;}gso;
         $toencode =~ s{>}{&gt;}gso;
         $toencode =~ s{"}{&quot;}gso;
...
                $toencode =~ s{'}{&#39;}gso;
                $toencode =~ s{\x8b}{&#139;}gso;
                $toencode =~ s{\x9b}{&#155;}gso;
...
                     $toencode =~ s{\012}{&#10;}gso;
                     $toencode =~ s{\015}{&#13;}gso;

[download]

That's at least 9 uses of /o with no variable interpolation in the pattern.

But CGI also doesn't use strict, has no spaces after commas, uses C-style for-loops where lists where more efficient and better readable, assumes that the IP address "0" equals "127.0.0.1", has ugly #-laden comments, etc... So is the use of /o really more efficient when no variable interpolation is used, or is this yet another strange thing in CGI.pm. (Excuse me for being so negative about CGI.pm, but having read it, I prefer my own set of functions even more.) 

44696420796F7520732F2F2F65206F
7220756E7061636B3F202F6D736720
6D6521203A29202D2D204A75657264

Replies are listed 'Best First'.
Re: Re: Re: Re: •Re: Find illegal ASCII characters
by IlyaM (Parson) on Mar 09, 2002 at 01:06 UTC
    Adding /o to regexps with no variable interpolation doesn't hurt anybody. It just ignored. I don't think it can be counted as bad style since there is no anything bad in doing it.

    --
    Ilya Martynov (http://martynov.org/)

[reply]

      Adding /o to regexps with no variable interpolation doesn't hurt anybody. It just ignored. I don't think it can be counted as bad style since there is no anything bad in doing it.

      There are a lot of things that do nothing at all, and in my book still are bad style: 

      for (...) {
    ...
}; # semi colon

"This is a string literal that will be optimised away and doesn't real
+ly hurt run-time performance. Actually, string literals in void conte
+xt are an easy way of having multi-line (nested if wanted) comments (
+but don't).";

s/\</\./g; # both don't need escaping

$I_JUST_LIKE_USING_VARIABLES_LIKE_THIS = "and it doesn't hurt performa
+nce";
$I_JUST_LIKE_USING_VARIABLES_LIKE_THIS = "it is, however, very bad sty
+le";

      [download]
      I think I could think of many more examples of pieces of code that are bad style, but do work, don't hurt anybody and/or even are ignored.

      I think it's bad to use /o when it's not needed, just like using escapes where they don't serve any purpose (note: escaping to avoid fscked-up syntax coloring is a valid excuse :). 

      44696420796F7520732F2F2F65206F
7220756E7061636B3F202F6D736720
6D6521203A29202D2D204A75657264

[reply]
[d/l]

In Section Code Catacombs