[dominik-appsilon]

Summary

This PR adds a new metric, correctness_lint_count, which uses {lintr} to count code patterns that are likely to cause bugs or incorrect behaviour. The metric counts lints from three lintr tag categories — correctness, common_mistakes, and robustness — and exposes the full lint results as auxiliary data via correctness_lints.

The intent is to capture functional quality: real programming mistakes, silent bugs, and portability hazards — not code style, naming conventions, or formatting preferences (those are left to {lintr}'s style tag, which is intentionally excluded).

This closes #38 .

Discussion

Including correctness and common_mistakes tags

The scope of lints I propose is a bit different from the one discussed in #38. Namely, besides robustness linters I would argue that we should also care about correctness and [https://lintr.r-lib.org/reference/common_mistakes_linters.html](common mistake) lints.

The correctness catches unambiguous bugs like duplicated arguments, missing arguments or mismatched format strings in sprintf(). The common_mistakes catches errors like using single & or | in conditional expressions or comparison to NA using ==.

Filtering out style linters (or other potentially opinionated linters)

Current implementation is the simplest possible -- we just check lints from each of the categories and report them as is. There are a few caveats like the fact that some of those lints are still classified as style lints as opposed to warning or error types. We could theoretically filter them out -- either by filtering the lints themselves or excluding the linters from the set we are using (so instead of selecting all filters with given tags we could pick them manually). This would exclude e.g. the undesirable_function_linter which just checks usage of functions from given predefined set. And this actually connects us to another question,

Configurable linters

Are we happy with the predefined configuration of some of those linters? Namely:

• undesirable_function_linter (in robustness): flags functions like sapply, attach, setwd, source, options. Some of these are genuinely hazardous in package code (attach, setwd), while others (sapply) are more of a stylistic preference. I feel like we cannot find one-size-fits-all solution so we should either use base set (as we currently do) or exclude the linter entirely.
• undesirable_operator_linter (in robustness): flags <<-, :::, and ->>. The use of <<- and ::: can be legitimate in some contexts (e.g. <<- in {R6} or reference classes, ::: when accessing internal functions deliberately; well, we're using them on our own in the {val.meter}). Should these be excluded or configured?
• backport_linter (in robustness): without an explicit minimum_r_version configured, this linter defaults to the running R version and effectively flags nothing. Should we expose a package option so users can set a minimum R version for their assessment?

Counting fraction of lint-free lines

Finally, I would like to have some fraction-like metric accompanying the absolute value provided by the already implemented linter. The one I am imagining is:

total_loc <- count_r_loc(path)   # counts number of non-blank, non-comment `.R` lines in `R/` (and maybe also `tests/`?)
linted_lines <- count_linted_lines(lints) # counts distinct lines that contain at least one lint
correctnesss_lint_free_fraction <- 1 - linted_lines / total_loc

[codecov-commenter]

Codecov Report

❌ Patch coverage is 95.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 33.41%. Comparing base (b4cabee) to head (aaa83b4).
⚠️ Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
R/data_lints.R	95.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #45      +/-   ##
==========================================
+ Coverage   25.86%   33.41%   +7.55%     
==========================================
  Files          35       37       +2     
  Lines        1481     1661     +180     
==========================================
+ Hits          383      555     +172     
- Misses       1098     1106       +8     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dominik-appsilon]

Okay, I've made the following changes based on our discussions:

• List of lints is now configured via a new option. This option allows specifying linters by name. This option is less ideal than specifying linters as objects but I decided to go this way because otherwise we would need to have a dependency on the {lintr} package -- current approach does not require it. A different solution would be to have a special value of NULL which could be substituted by the default set of linters. Let me know if you think it would be better.
• The default list of linters is now manually curated. It consists of all robustness, correctness and common_mistake linters except a few: backport_linter, duplicate_argument_linter, missing_argument_linter, strings_as_factors_linter, undesirable_function_linter, undesirable_operator_linter, missing_package_linter, namespace_linter. Those either require configuration or are environment specific.
• I implemented counting fraction of lint-free lines. I am using function from {lintr} to actually detect parsed expressions and the values used to detect files and dirs are based on the {lintr} functions so it should consider all possibly lintable lines

So now we have the following new features:

• 1 new internal data object: "lints"
• 2 new metrics: "lint_count" and "lint_free_fraction"
• 1 new option: "lint_linters"
• New tests & docs

[llrs-roche]

It looks good, I think it is time we merge this. Just one (last) suggestion about using lintr without checking if the package is present: I think all lint data sources should check that lintr is installed with the suggests = "lintr".

[dominik-appsilon]

Thanks @llrs-roche ! I added the guard. Additionally, I added lintr to suggest field of metrics to enforce check at higher level as well.