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{<}{<}gso;
$toencode =~ s{>}{>}gso;
$toencode =~ s{"}{"}gso;
...
$toencode =~ s{'}{'}gso;
$toencode =~ s{\x8b}{‹}gso;
$toencode =~ s{\x9b}{›}gso;
...
$toencode =~ s{\012}{ }gso;
$toencode =~ s{\015}{ }gso;
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
| [reply]
[d/l] |
| [reply] |
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";
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] |
