On Dec 20, 2006, at 11:06 AM, Michael G Schwern wrote:
Well, maybe not exactly - I can probably make good arguments for
inline
annotation.
Allow me. :)
The current scheme won't track changes to the source file well.
Using file + md5 rather than file + line helps some, but problems
remain. Not dealing well with code change is a much worse problem
than having to markup your source. You markup once. You change
code a lot. O(1) vs O(n).
* What happens when I trivially alter an uncoverable line? Add a
comment, change the spacing,
move it to a different indentation level?
* What happens when I have two duplicate lines in the same file,
one I want to cover one I don't?
* What happens when I rename a file with uncoverable elements?
* What happens when I move code from one file to another?
And the usual drawbacks of not being inline.
* Having to drag around a separate file just for coverage.
* Having to shell out to a separate utility and describe to it
which bit not to cover.
Additionally, the use of an md5 sum to identify the line means I
cannot easily know which lines are marked as uncoverable even with
the uncover file open in front of me.
I predict a lot of churn of the form:
1) Edit the code
2) Run the coverage
3) Read warnings about uncover lines no longer existing in the
source file
(maybe, they've just been altered, maybe they've been deleted.
Who knows?)
4) Carefully scanning my coverage results to see what was marked as
uncovered has lost
that marker because of a trivial change to the line.
5) Updating the uncover file.
This is no fun.
If I might make a suggestion for an inline syntax. This is
statement, subroutine, branch and condition respectively.
statement; # uncoverable "Optional Reason"
sub foo { # uncoverable "Optional Reason"
...
}
if( condition ) { # uncoverable "Optional Reason"
if( this || that ||
unreachable # uncoverable "Optional Reason"
)
{
...
}
The condition coverage marker does require some reformatting of the
code. That probably won't be a big deal given how infrequently it
should be used. However, maybe something a bit more explicit could
be used.
if( this || that || unreachable ) { # uncoverable condition/3
"Optional Reason"
...
}
That states that the 3rd part of the condition on that line is
uncoverable.
IF you want a powerful, inline markup syntax for Devel::Cover (and
that's a BIG if), you might want to look at what we did for
Perl::Critic. We have scoped, blocked, and line-oriented pragma-like
comments that selectively disable Perl::Critic. An optional
parenthesized substring turns off just matching policies.
Single line style:
eval $str; ## no critic(StringyEval)
On/off-style:
## no critic(StringyEval)
eval $str;
## use critic
Scoped style:
sub {
## no critic(StringyEval)
eval $str;
}
eval $str; # triggers a violation...
The scoped style is possible because we are using PPI to parse the
code into a DOM.
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
