As long as you're use-ing re '/flags' anyway, add /ms to /x to relieve that small, nagging, maddening ache in your left temporal region arising from always having to worry about just what . ^ $ do, and the difference between single- and multi-line modes. (Another indisputable bit of wisdom from TheDamian.)
Give a man a fish: <%-{-{-{-<
| [reply]
[d/l]
[select] |
Indisputable, you say? Perhaps not.
By avoiding use re I never have to worry about what . ^ $ do because they mean precisely what they have done for the last couple of decades, viz:
- . matches any single character other than \n
- ^ matches the start of the string
- $ matches the end of the string
Could not be simpler. If anyone should need to use /m or /s then they can tack that on to the regex as a modifier and anyone reading the code sees that it's clear that in this one case things might be different. (I've disregarded /x here as nobody ever needs that - it's just for syntactic clarity)
However, if someone has done as you espouse then I might be entirely unaware of it because this declaration might occur nowhere near the regex I would currently be examining. A module with several thousand lines is (alas) not uncommon and a use re declaration on line 1000 is no use to me if I'm looking at line 4000 trying to work out why the hell the regex is misbehaving.
It is my considered opinion therefore that use re /flags is likley to cause more problems than it solves with the notable exception of its use in a strictly limited lexical scope of a handful of lines or (at worst) a single self-contained subroutine. It's unlikely that I would ever use it even in that scenario, except perhaps to negate what some less charitable programmer might have set up more globally.
Other opinions are available, of course, and there are no doubt various subjective reasons to choose one approach or the other. But your assertion that it is indisputable is unfounded.
| [reply]
[d/l]
[select] |
It is my considered opinion ... that use re /flags is likley to cause more problems than it solves ...
I tend to agree, except perhaps in the context of a "shop standard" situation. (And in such circumstances, I would not feel so strongly about the issue that I would go so far as to refuse to cash my paycheck.)
Personally, I tend to go back and forth between pre- and post-Perl version 5.14 often enough that worrying about whether '/flags' is supported just isn't worth the mental effort. This is all the more true when trying to cobble together PerlMonks regex examples.
-
. matches any single character other than \n
-
...
Could not be simpler.
Actually, ". matches any single character" is simpler. Here we get into the related religious disputation concerning the uniform use of an /xms tail on all regex operators. As you say, this is very much a personal preference. My own preference is to avoid "X always means Y (other than when it doesn't)" types of rules, especially in the highly counter-intuitive, already plenty confusing realm of regexes. As to the ^ $ operators, my opinion, again (and in line with TheDamian), is that these should do one thing and one thing only (the /m thing), with the \A \z \Z operators fulfilling more limited and common non-/m purposes. (As to the seniority of the latter operators, they have been around nearly for decades, at least since 5.8.8. My vague recollection is that they go back to very close to T0 of the Perl 5 epoch, so probably at least for decades!)
These are my principles. If you don't like them, I have others.
... your assertion that it is indisputable is unfounded.
And was also intended for comic effect :)
Give a man a fish: <%-{-{-{-<
| [reply]
[d/l]
[select] |
