From: Karen Etheridge Date: Sat, 8 Sep 2012 19:11:31 +0000 (-0700) Subject: use link markup whenever referring to this module, vs. strictures in general X-Git-Tag: v1.004002~3^2~3 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=p5sagit%2Fstrictures.git;a=commitdiff_plain;h=0eb0d0372c1076d64a666ff40722089816bef175 use link markup whenever referring to this module, vs. strictures in general --- diff --git a/lib/strictures.pm b/lib/strictures.pm index e2353f7..913198f 100644 --- a/lib/strictures.pm +++ b/lib/strictures.pm @@ -117,7 +117,7 @@ Note that C may at some point add even more tests, with o version increase, but any changes to the effect of C in normal mode will involve a major version bump. -If any of the extra testing modules are not present, strictures will +If any of the extra testing modules are not present, L will complain loudly, once, via C, and then shut up. But you really should consider installing them, they're all great anti-footgun tools. @@ -140,7 +140,7 @@ syntax (and not so obvious mistakes that cause things to accidentally compile as such) get caught, but not at the cost of an XS dependency and not at the cost of blowing things up on another machine. -Therefore, strictures turns on additional checking, but only when it thinks +Therefore, L turns on additional checking, but only when it thinks it's running in a test file in a VCS checkout - though if this causes undesired behaviour this can be overridden by setting the C environment variable. @@ -174,7 +174,7 @@ with a version number on it and does the version check. =head1 EXTRA TESTING RATIONALE Every so often, somebody complains that they're deploying via C -and that they don't want strictures to enable itself in this case - and that +and that they don't want L to enable itself in this case - and that setting C to 0 isn't acceptable (additional ways to disable extra testing would be welcome but the discussion never seems to get that far). @@ -205,10 +205,10 @@ differences between the production and the development environment. I wrote L to explain this particular problem before L itself existed. -As such, in my experience so far the strictures extra testing has +As such, in my experience so far the L extra testing has -avoided- production versus development differences, not caused them. -Additionally, strictures' policy is very much "try and provide as much +Additionally, L' policy is very much "try and provide as much protection as possible for newbies - who won't think about whether there's an option to turn on or not" - so having only the environment variable is not sufficient to achieve that (I get to explain that you need to add @@ -218,7 +218,7 @@ is important). I make no claims that the heuristic is perfect - it's already been evolved significantly over time, especially for 1.004 where we changed things to -ensure it only fires on files in your checkout (rather than strictures-using +ensure it only fires on files in your checkout (rather than L-using modules you happened to have installed, which was just silly). However, I hope the above clarifies why a heuristic approach is not only necessary but desirable from a POV of providing new users with as much safety as possible,