Executive summary: "There should be a tool" (sorry, I'm not volunteering any time soon) that could be added to $VCS diff (say, "git coverage-diff" or "git diff --coverage"). Chris Withers writes: > It's an interesting point; I personally don't see much value in coverage > of less than 100%, if you're going to look at coverage: no-one is going > to focus on or potentially even notice whether coverage moved from 99% > to 99% (no typo), even though a bunch of new uncovered code may have > been introduced. I agree with the point you're making (that the difference between 100% and 99% is a very significant indicator that "something needs to be done here, it's obvious what, and [depending on project process] it's obvious who, too"), but it's also true that 99% is better than 98% and definitely better than 90% or less. Your point that it matters *which* 1% is more important, I think (see "Executive summary"). > If people are actually using these blocks, then so be it, but it feels > like the people who want them to stick around are saying they're using > them just on the off chance they might use them, which feels like a poor > reason to keep a bunch of dead code around. At least one person says he uses it, although I don't know how that fits with Robert's statement that "it was never needed". Steve
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4