You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Originally reported by Jonas Kölker (Bitbucket: jonaskoelker, GitHub: jonaskoelker)
99% of what I use python-coverage for is something like this:
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:
(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.
The text was updated successfully, but these errors were encountered: