simple comment triggers commented_code_linter

[MichaelChirico]

weird that this triggers commented_code_linter. seems like a bug.

Originally posted by @MichaelChirico in https://github.com/r-lib/lintr/pull/923#discussion_r825407071

[AshesITR]

The particular instance could be fixed if comments within comments were ignored in the test for code candidates. Maybe parseable() could be refactored to codeish() and check whether the parsed code without comments is meaningful in some way.

[MichaelChirico]

A list in a comment is also triggering the linter:

https://github.com/r-lib/lintr/blob/09fdc8a523334f72ebcb25e931f43b0e1ffb3d14/R/object_usage_linter.R#L113-L119

I guess * could be used for bullets? Or else we don't use () in such a list?

[MichaelChirico]

By the way, I don't see anything in the style guide about including/excluding code from comments. Should this be a default linter to begin with?

[AshesITR]

I found it a very common beginner mistake among my colleagues - especially if not used to the wonders of git being capable of resurrecting every line of code if need arises.

Maybe a way to get fewer false positives would be to define some kind of minimal complexity that the potentially commented code must have when parsed?

Things I would rather see linted:

• assignments to objects (especially in-scope) -- we have a false positive currently with x = 1 in our tests, but I think it's acceptable since uncommenting this could actually drastically change function behaviour.
• function calls with explicit non-empty arguments -- this would not include our current false positive case due to empty arguments, if we allow a leading unary minus

Not sure if that misses any troublesome code. Should optionally be upgradable to the current, more aggressive linting though.

[MichaelChirico]

Definitely one option like allow_no_calls that requires at least one ( call seems likely to eliminate many false positives.

[IndrajeetPatil]

Minimal test case:

library(lintr)

lint(
  text = "# cf #923 and sort()",
  linters = commented_code_linter()
)
#> <text>:1:3: style: [commented_code_linter] Commented code should be removed.
#> # cf #923 and sort()
#>   ^~~~~~~~~~~~~~~~~~

^{Created on 2022-12-19 with reprex v2.0.2}

[MichaelChirico]

define some kind of minimal complexity that the potentially commented code must have when parsed?

I am converging on this being the right approach. Such a metric can be used to parameterize other linters as well.

However, I had hoped we could just re-use cyclocomp::cyclocomp() for this, but I don't think that measure of complexity aligns with what we want here.