-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
object_camel_case_linter is over-eager #108
Comments
.GlobalEnv is defined in the base functions, so should definitely be excluded in recent versions of lintr (see jimhester/lintr/R/objects_linter.R#L120-L161) As you state Determining variables defined by a package is actually non-trivial to do (and in some cases impossible without evaluating the code), so I am unsure if that is the best approach here. Also once a user fixes the assignment (e.g. changing I do agree however that there are still more false positive lints due to external definitions than I would like, perhaps more can be done to import the exported namespaces of packages in |
There’s no perfect way. However, as we’ve seen all alternatives lead to errors, and I think that implementing the strategy I suggested would significantly lower the false positive rate, while barely increasing the false positive rate. However this is just a hunch, I have no evidence either way, and my suggestion does have some caveats.
My package is not on CRAN (for this and similar reasons). But I need to access R internals because R doesn’t otherwise expose the proper API for my purposes (my package modules is recreating parts of R’s package mechanism). |
Incidentally, I don’t know why |
Things like
are definitely false positive... IMO it would also be enough to check that an object is assigned something (e.g. |
This is fixed in #214 . Please, do open a new issue if you find some names that get linted when they should not (or inversely). |
I get multiple errors “Variable and function names should be all lowercase” for using predefined names such as
.GlobalEnv
orgetRegisteredNamespace
(the latter is an internal name, called via.Internal(getRegisteredNamespace(…))
) orcontext$cppSourceFilename
.All of these cases are names from elsewhere that my package is using, not defining. In other words, I have no control over them. Currently, the linter only excludes names found in attached packages but as the above shows, this leads to many false positives. Ideally, the linter should only complain about names that are defined in the package (i.e. that are on the left side of an assignment operator or, optionally, the first argument of
assign
, or are inside a function argument definition).There’s one complication in the proposal: it needs to special-case
c
andlist
calls to ensure that the following code raises the warning:The same is probably true for
object_snake_case_linter
.The text was updated successfully, but these errors were encountered: