Should there be optional undesirable_object_name() linter?

[IndrajeetPatil]

A number of potential object names can cause trouble because they also represent commonly used function names.
Here are a few that come to mind (can definitely be expanded based on feedback):

t, c, df, I    # (from `{base}` package)
data           # (from `{utils}` package)

In edge cases, these produce the cryptic object of type 'closure' is not subsettable error:

df <- data.frame(x = 1)

# lot of code
# ...

rm(df)

# some other code not involving `df`
# ...

# forgot that I've already removed `df`
df$x
#> Error in df$x: object of type 'closure' is not subsettable

^{Created on 2023-01-09 with reprex v2.0.2}

So should there be an undesirable_object_name() linter that would caution users to avoid such variable names?
Examples that would produce lints:

df <- 5L # literal
t <- list(1, 2) # generic vector
c <- c(1, 2) # atomic vector
# etc.

That said, I am wondering if this linter should also be applied to function names because one might deliberately overload the base function with a custom one. As Patrick Burns notes in his book, such overloads can cause quite the confusion:

c <- function(x) x * 100
par(mfrow = c(2, 2))
#> Error in c(2, 2): unused argument (2)

^{Created on 2023-01-09 with reprex v2.0.2}

[MichaelChirico]

duplicate of #376?

[IndrajeetPatil]

Definitely related, but this issue has a much narrower scope in mind.

Checking against every function name in default packages (stats, graphics, grDevices, utils, datasets, methods, base) is going to be expensive, so I thought restricting such a check to a few functions might be a good compromise.

Maybe we keep this open until we decide either way in #376?

[MichaelChirico]

I have an existing implementation that used something like the top 100-most overloaded symbols (at least in our internal code)

[IndrajeetPatil]

Closed by #2307