You can't have 100% test coverage with these kinds of bugs, because these bugs create unreachable expressions.

You can either find out you have these bugs from lint errors or you can find out by finding them in code coverage reports while chasing 100% code coverage. Most people would obviously prefer the former.

Neither would malloc(), and yet we still like Rust's borrow checker.

I've never seen a project with 100% condition tests coverage. Sure, they exist, but they're as rare as unicorns.

I think you’re technically correct. But if you are someone who is writing 100% branch coverage code this rule could still be useful. It will quickly point out parts of your code base that are going be impossible to test with 100% coverage.

100% coverage is very rare outside safety critical code. People are much more willing to invest time in adding features than writing (often boring, repetitive and tedious) tests just to get perfect coverage -- finding a bug later is a risk people are willing to take.

And even 100% doesn't mean much -- you can easily come up with examples where you have 100% coverage but there are still bugs.

100% branch coverage, which is even more rare. I've done it for a couple of projects, and it's really useful (there were bugs hidden even in the last few percent), but it is a decent amount of work.