This draws the dependencies between variables. This function is useful to detect dead code and variable clusters. By default the variable is shown a new time when it's overwritten or modified, this can be changed by setting expand to FALSE.

  expand = TRUE,
  refactor = c("refactored", "original"),
  out = NULL



The function, script or expression to draw


A boolean, if FALSE a variable name is only shown once, else (the default) it's repeated and suffixed with a number of *


If using 'refactor' package, whether to consider original or refactored code


a path to save the diagram to. Special values "html", "htm", "png", "pdf", "jpg" and "jpeg" can be used to export the object to a temp file of the relevant format and open it, if a regular path is used the format will be guessed from the extension. Other special values "data" and "code" can be used for respectively retrieving the graph data as a data frame and the diagram code.


flow_vars() returns a "flow_diagram" object by default, and the output path invisibly if out is not NULL (called for side effects).


Colors and lines are to be understood as follows:

  • The function is blue

  • The arguments are green

  • The variables starting as constants are yellow

  • The dead code or pure side effect branches are orange and dashed

  • dashed lines represent how variables are undirectly impacted by control flow conditions, for instance the expression if(z == 1) x <- y would give you a full arrow from y to x and a dashed arrow from z to x

expand = TRUE gives a sense of the chronology, and keep separate the unrelated uses of temp variables. expand = FALSE is more compact and shows you directly what variables might impact a given variable, and what variables it impacts.

This function will work best if the function doesn't draw from or assign to other environments and doesn't use assign() or attach(). The output might be polluted by variable names found in some lazily evaluated function arguments. We ignore variable names found in calls to quote() and ~ as well as nested function definitions, but complete robustness is probably impossible.

The diagram assumes that for / while / repeat loops were at least run once, if a value is modified in a branch of an if call (or both branches) and expand is TRUE, the modified variable(s) will point to a new one at the end of the ìf call.