in reply to Re^8: Best practice or cargo cult?
in thread Best practice or cargo cult?

Having upvoted this several hours ago--it strikes a cord with several of my recent posts--I got to thinking about it a little more.

When developing a regex, I generally type m[]msx automatically. Long before I get around to deciding what goes inside the regex. I've been doing this for a long time. I think that an appropriate supersearch of my posts would turn up instances that use this, that long predate the advent of PBP. From memory, these would include several instances where I was castigated for using /s and/or /m on regexes that ultimately did not need these options.

I do this because I've found that it makes developing the regex easier. Using /x allows me to space out the elements and spread them over several lines which is easier to read. It also allows me to comment out chunks of the regex and then uncomment them one at a time, which helps me track down which part is preventing matches.

With /s & /m, despite that when I read the documentation their function and purpose is very clear to me, I always have to think hard about which is required to enable what, when I'm in the process actually writing regexes. It's simply easier to enable both and not get distracted from my purpose, than constantly decide which is appropriate, or is no longer appropriate, as I try out different possibilities of achieving my goal.

Enevitably, they often get left in place once the regex is working, regardless of whether they are actually required for the final regex or not. That is, unless I have cause to go back and consider the efficiency of the regex, in which case I may well opt to remove /x which is known to slow regexes by a measurable margin. Under the circumstances where I might consider removing /x, I will usually also try removing the other two. I tend not to reason about whether they are needed, I simply try removing them and if the testcases still work, I leave them off. If not, I put them back one at a time until it does. Crude, but simple.

And that why I make a distinction between the book, with it's set of guidelines--things to consider, along with their supporting arguments; and the module with it's unreasoned, automatic, blind enforcement of those guidelines.

As a tool, that allows me to force me to (re-)consider my choices, it's probably valuable. But used by others to blindly enforce a set of pedantic, capricious and sometimes arbitrary laws upon the code I write, it would be completely unacceptable unless the default behaviour pretty much mirrors the 'normal' settings of Perl with warnings and strict enabled.

There are probably a few extra warnings that could be enabled by default--though if there are, one wonders why these aren't a part of the standard warnings produced by the compiler. But anything beyond that should need to be specifically enabled, not disabled.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.