Paul Johnson wrote:
On Mon, Jul 11, 2005 at 02:54:19PM -0700, Michael G Schwern wrote:
On Mon, Jul 11, 2005 at 11:22:51PM +0200, Paul Johnson wrote:
my $foo = $bar || default(); # DC ignore X|0
"Hey, Devel::Cover! Ignore the case where the right side of this logic is
false."
I wasn't particularly happy with the idea of needing to change the
source code just to satisfy some tool. I feel the same way about doing
things to shut up lint, for example, or to satisfy some arbitrary
metric. That's why I've initially stored information in a .uncoverable
file.
Guh! .uncoverable would presumably be line number based. That means
every time you edit your source file you have to change all the lines in
.uncoverable. *shudder*
Now, would I do that?! It's actually based on the MD5 hash of the line
which means you only need to change it when you have changed the line,
which you would presumably (there's that word again) be doing anyway.
theres another way to approach it.
1. emit a text version of the coverage failures which
a. has same info as html details - ie line# conditionals, code
b. starts with a comment.
2. use that 'exact' format as your ignore directive
a. except that # means its entirely ignored
b. user removes # to cause report supression
now, full power (and a bit of tedium) is in users hands.
by just renaming the output to .uncoverable (or whatever),
they get a do-nothing version thats up-to-date with their code,
and thats easy to use to supress everything.
You could call it a feature that line-changes invalidate supressions,
since the code being tested has changed ;-)
Adding pattern matching on line # is easy, and would make the .uncoverable
file a bit more flexible, you probly want \Q \E around the code itself,
with loud caveats about not doing intelligent src-code matching.
Hey, its supression, it shouldnt be too easy.
(We all know the chilling effect of jailing journalists! :-O )
And updating supression files shouldnt be a daily occurrence,
more of a 'once per release, before management looks at the html' ;-)
Why is it that my TODO list only gets longer?
Ive been wanting to spend enough time studying the code that I grok the
way it works, it would be a worthy pod contribution to your work.
It should increase the approachability of the module, and improve odds that
others would feel they had a chance of successfully completing the TODO
items.
The code has a steep grokking curve.
