Here is the approach we are going to take to rationalize the way we manage "Best Value". 1. At metric level, we should be able to optionally define if there is "Best Value" and what this value is 2. For any ressources at FILE level, measures will be recorded only if different from the best value 3. In the drill down, a resource will be displayed only if its measure is different from "Best Value" 4. The Sonar API must return the default value if no measure exists in the DB

Metric	Best Value
coverage_line_hits_data	N/A
lines	N/A
ncloc	N/A
classes	N/A
files	N/A
directories	N/A
packages	N/A
functions	N/A
accessors	N/A
public_api	N/A
complexity	N/A
class_complexity	N/A
function_complexity	N/A
file_complexity	N/A
class_complexity_distribution	N/A
function_complexity_distribution	N/A
uncovered_complexity_by_tests	N/A
statements	N/A
comment_lines	N/A
comment_lines_density	N/A
public_documented_api_density	100
public_undocumented_api	N/A
Commented-out lines of code	0
tests	N/A
test_execution_time	N/A
test_errors	0
skipped_tests	0
test_failures	0
test_success_density	N/A
test_data	N/A
coverage	N/A
duplicated_lines	0
duplicated_blocks	0
duplicated_files	0
duplicated_lines_density	0
duplications_data	N/A
usability	100
reliability	100
efficiency	100
portability	100
maintainability	100
weighted_violations	N/A
violations_density	N/A
violations	0
blocker_violations	0
critical_violations	0
major_violations	0
minor_violations	0
info_violations	0
alert_status	N/A
profile	N/A
burned_budget	N/A
team_size	N/A
business_value	N/A