Skip to content

New linter for multiple assignments #2611

Open
@MichaelChirico

Description

@MichaelChirico

It could be nice to catch error-prone behavior in package development like:

my_function <- function(...) { ... }

# lots of code

my_function <- function(...) { ... }

i.e., we define my_function() in multiple places. Then by accident we make a bug fix to the former implementation and scratch our heads why it has no effect on the installed package.

That's the simplest ideal, but there are lots of gotchas here that are potential roadblocks:

  • my_function() might be defined in separate source files (e.g. R/aaa.R, R/bbb.R), and {lintr} currently doesn't maintain any sort of global state like that (and pkgload::load_all() doesn't help since the first definition will simply be overwritten in the package namespace).
  • It would be annoying to be linted for redefining a or b or x or i, simple placeholder variables that might come up several times in an analysis, especially if they're defined in different scopes that don't interact at all anyway.
  • It's perfectly reasonable, though maybe not always the best practice, to write multiple my_function <- ... definitions in different branches of if/else, e.g. to offer a different version of a function in different R (or other upstream package) versions. So we wouldn't want to lint that case.

That said, I think it's possible to come up with something useful & improve it over time.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions