object_name_linter catches nonalphanumeric operator names

[MichaelChirico]

 writeLines("
`%++%` <- function(x, y) x+y
", tmp <- tempfile())

lintr::lint(tmp, lintr::object_name_linter())
# /tmp/Rtmp0dwFUb/file7f2d15642314:2:1: style: Variable and function name style should be snake_case.
# `%++%` <- function(x, y) x+y
# ^~~~~~

Seems like that's not possible to put into snake case...

[AshesITR]

Such functions should be rare enought to warrant an occasional # nolint imo.
Note that `%my_op%` <- function(x, y) x + y lints fine

[MichaelChirico]

In this case, I am staring at what lintr is telling me and thinking "How would I even do that?", so if there's an easy fix, I think we should do it and avoid needless confusion. I think (somewhat speculative) it's more uncommon for operators to have alphanumerics than not, so conditional on writing operators, it seems this warning is likely to arise.

[AshesITR]

Yeah, I see that happening.
What should happen for e.g. %T>% from {magrittr}?
Maybe a new option check_operators = TRUE could be added and that would allow you to do whatever with objects that are named %something%?

I mean you'd certainly want a lint if a variable named `++` were used, no?

[MichaelChirico]

Not a perfect search but a grep-based approach on my CRAN mirror turned up these operators:

with alphanumeric

in, nin, chnin, btwn, nin, !in, and, nin, alike, chin, iscall, between, inrange, like, ilike, flike, in, ni, dominates, isDominatedBy, into, nest, add_rows, merge, calc, calculate, row_in, col_in, thru, a, r, to, to_list, if_na, na_if, then, matrixPower, matBinPower, bq, bt, bq, !in, n, n, L*, nin, check&&, check||, c=, union=, or, except, between, dof, dofc, like, nlike, ilike, nilike, regexp, iregexp, over, like, rlike, regexp

without alphanumeric

??, *, :::, ||, $, @, , >>, >>, <<, <>>, <<<, >|, |<, +=, -=, <=, ^, &, ||, ||, ||, +, <=>, <!=>, ||, :::, :::, *, =, ==, *, {*}, *[, ]*, *{, }*, *|, |*

My gut is to treat %++% differently than ++ (by default, don't really see the need for an option). A matter of how hard it is to implement.