Description
Originally reported by Jonas Kölker (Bitbucket: jonaskoelker, GitHub: jonaskoelker)
99% of what I use python-coverage for is something like this:
- Run my test suite and generate a report
- Look at the report to see which module needs more work (~= is least covered)
I suspect this use case is very common. When you click on a table header, it's fair to assume that your gaze is somewhere very close to the table header. If the next thing you want to see appears right next to the table header, you save the extra step of either scrolling to the bottom of the page or clicking again. That means the default sort orders would need to be:
- missing: largest to smallest
- partial: largest to smallest:
- coverage: smallest to largest
- excluded: largest to smallest (not exactly "work needed", but perhaps "suspicious")
- statements: largest to smallest, just for symmetry with missing and excluded
- branches: largest to smallest, just for symmetry with partial
(TL;DR: coverage ascending, the rest descending)
At least in 3.4, everything is sorted ascendingly, so everything except for coverage should be inverted. Of course, if you add column sorters to the bottom of the table and want to optimize the gaze proximity of the last action and the next action---column sorter and work-needy row(s)---you want the bottom defaults to be the inverse of the top defaults.