在dplyr中使用get()替代SE是否存在弊端？

Great question—you’ve hit on a common pain point when working with dplyr’s non-standard evaluation (NSE) vs. standard evaluation (SE) workflows. Let’s break down your questions about get() and explore better, more robust alternatives.

First: Is using get() problematic? #

Short answer: It works for basic cases, but it comes with subtle risks and compatibility gaps that make it less reliable than dplyr’s intended SE tools. Here’s why:

1. Scope ambiguity #

get() defaults to looking for objects in the calling environment, not exclusively your data frame. If there’s a global variable with the same name as your target_column, get() might accidentally pull that instead of your data frame column. For example:

# Global variable with the same name as a data frame column
target_column <- "wrong_value"

# Your function would use the global variable instead of the intended column
find_dataset_inconsistencies(my_df, "actual_target", c("col1", "col2"))

This is a silent, hard-to-trace bug that can mess up your results.

2. Compatibility with dplyr extensions #

get() doesn’t play nice with dplyr’s backend integrations like dbplyr (for databases) or dtplyr (for data.table). These tools translate dplyr code into SQL or data.table syntax, and get() can’t be parsed into those languages—you’ll get errors when trying to run your function on a database connection.

3. Future-proofing #

dplyr has moved away from the old _at/_if/_all verbs (like group_by_at) in favor of across() and tidy-select syntax. get() doesn’t align with this modern workflow, meaning your code might become outdated as dplyr evolves.

4. Performance (minor, but worth noting) #

While the hit is tiny for most datasets, get() adds an extra layer of environment lookup that isn’t necessary with purpose-built dplyr tools. For extremely large datasets, this could add up, though it’s rarely the biggest concern.

Better alternatives to get() #

dplyr provides safer, more idiomatic ways to handle string column names. Here are two recommended approaches:

Option 1: Use the .data pronoun #

The .data pronoun explicitly references columns from your data frame, eliminating scope ambiguity. It’s clean, readable, and compatible with all dplyr backends:

find_dataset_inconsistencies <- function(df, target_column, cols_to_use) { 
  df %>% 
    group_by(across(all_of(cols_to_use))) %>% 
    summarise(uTargets = n_distinct(.data[[target_column]]), .groups = "drop") %>% 
    filter(uTargets > 1) 
}

.data[[target_column]] tells dplyr: "Look only in the current data frame for this column name as a string."

Option 2: Use rlang::sym() and unquoting (!!) #

If you prefer working with symbols (dplyr’s native NSE objects), you can convert your string to a symbol and unquote it with !!:

find_dataset_inconsistencies <- function(df, target_column, cols_to_use) { 
  target_sym <- rlang::sym(target_column)
  df %>% 
    group_by(across(all_of(cols_to_use))) %>% 
    summarise(uTargets = n_distinct(!!target_sym), .groups = "drop") %>% 
    filter(uTargets > 1) 
}

This is explicit about the NSE workflow and works just as reliably as the .data approach.

Final takeaway #

While get() is readable for simple cases, it’s not the most robust choice. Using .data[[...]] or sym() + !! avoids scope bugs, works with dplyr extensions, and aligns with modern dplyr best practices. The readability gap is minimal once you’re familiar with these tools, and the safety gains are significant.

内容的提问来源于stack exchange，提问作者Thomas