EDIT: This explains the concept, and gives a minimal approach to testing (i.e., you should test more than this, but at least this). Of course, there are tools to automate this, but not for every (new) language.
There are many other types of code coverage, including branch/conditional coverage, state coverage and so forth that provide much greater depth of coverage that developers should look into using where possible. The Wikipedia article has a good introduction: https://en.wikipedia.org/wiki/Code_coverage.
Edit: I mean that is there anyone in 2016 who uses testing tools that cannot instrument code to calculate coverage automatically?
I didn't say that. Be wary of people who say they fully tested your code :)
Anyway, there's another (non-waterproof) approach: try to trigger all possible paths through the code (instead of all basic blocks), but the problem is that the number of paths can increase exponentially with code size.
The code-coverage approach, in contrast, is very cost-effecitve. For example, roughly speaking, it triggers all possible exceptions that your code can throw.
100% code coverage can _never_ be taken, as a figure, to indicate that testing is comprehensive.
Well, unless you count uncaught exceptions from things your code calls.
There are other types of coverages. Like branch coverage, which is more like what you've described. And path coverage. Path coverage tests that all independent paths are executed at least once but it's tedious and memory intensive to calculate and he hence impractical.