Function declarations defined after the return statement of a function are not marked as covered about istanbul HOT 8 CLOSED

That's because the statement coverage for the function is added just before it and doesn't get executed due to the early return.

I'm not going to fix this because it is non-trivial to do it correctly for the general case and I don't see the value of adding complexity to the instrumenter for this edge case.

Let me know if you don't agree.

from istanbul.

@gotwarlost can you add an option to not complain about "dead code" not being covered after the return statement ?

I really like the function declarations after statements in the function body coding style.

from istanbul.

So I think the real fix is to not consider function declarations as a "statement" at all. That way this case is easily covered.

But this fix, which in my opinion is correct, might cause a lot of people to yell at me because their coverage numbers "suddenly changed" (the numbers should go up in most cases so maybe they won't yell as loudly).

I'm still concerned about making this change for this reason.

from istanbul.

@gotwarlost bump the major version number. semver works.

from istanbul.

:)

from istanbul.

OK, I'm not going to consider function declarations as "not a statement" which will cause aforementioned ire (actually the coverage numbers go down because the percentage of uncovered statements will be higher now that the total number of statements has decreased).

I'm just going to consider function dclarations as a statement with an initial cover count of 1 so that function declarations will always be seen as covered no matter where you put it. This is mostly correct in that the function declaration is a statement and it is always executed from the compiler's viewpoint.

from istanbul.

Available in v0.1.38

from istanbul.

@gotwarlost nice! thanks :)

from istanbul.