3

I've been writing an R package and using lintr to tidy it up stylistically.

One problem I am seeing a lot is that my data.frame columns are named from the CSV and are capitalised, e.g. MyVariableName. This is outside my control and outputted data will need to follow the same style. Therefore I don't want to rename them on import as it will lead to confusion when following the code from inputted data.

I'm using the tidyverse and NSE. I also tend to use lots of quasi quotation stuff in the code (where I'm building up analysis from quoted building blocks, ie. defining lists containing:

rlang::quo(MyFirstVar + MySecondVar)

I've tried using .data$ to scope them but still get the warnings for that:

rlang::quo(.data$MyFirstVar + .data$MySecondVar)

I've found for dplyr select commands you can quote the column names as strings - so that solves some of the warnings.

Is there a way to suppress warnings about data frame column names?

symbolrush
  • 7,123
  • 1
  • 39
  • 67
Andrew Hill
  • 307
  • 2
  • 12

2 Answers2

1

lintr is a package to help you write with consistent style. If you have valid reasons for why you need to use camelCase instead of snake_case, I wouldn't try to circumvent that. I would definitely not try to remove warnings by changing your code. This will make it less readable, and the goal of a style guide is to have more readable and consistent code!

There are however other possibilities to suppress warnings when linting. If you look at the Readme.md at GitHub, there are at least two possibilities:

  • You can append each offending line with # nolint or whole blocks of code with # nolint start and # nolint end.
  • You can create a configuration file (.lint) in your project root and change the default linters.

Depending on how you call lintr when checking your code, there might be other options as well.

Thomas K
  • 3,242
  • 15
  • 29
  • The thing is I want to follow the style in all other circumstances - every variable within my code should be snake_case; just not the data frame columns which I can't control. Because of the data frame warnings, it's difficult to then find all the other instances which I want to ensure are style compliant. – Andrew Hill May 23 '18 at 08:51
  • Yes, then the first option is for you. Append each line where you need to use camelCase with `# nolint`. I assume, those are not the majority of lines in your package. For those lines you need to check manually, whether you adhered to the style, but that should not be difficult, since I don't expect the number of lines to be extremely high. – Thomas K May 23 '18 at 08:54
  • I think that is probably going to be the best solution (though a little distracting in terms of readability to litter the code with pseudo-commands, given the goal of style guide compliance is to improve readability!) Not sure whether this is a reasonable feature suggestion for lintr because there is a difference from an author's perspective between most R variable types, and data frame content (which may or may not be under the control of the package author). – Andrew Hill May 23 '18 at 09:11
  • There is some discussion in the issues over at Github about how function names from other packages (and with other styles) should be handled. They thought about parsing the namespace and excluding imported functions. I'm not sure if the implemented it, but if yes you maybe could hack around your problem by using `utils::globalVariables` for the offending names... – Thomas K May 23 '18 at 09:19
1

Hmm - by accident I appear to have solved my own answer.

Instead of using:

rlang::quo(.data$MyFirstVar + .data$MySecondVar)

You can use:

rlang::quo(.data[["MyFirstVar"]] + .data[["MySecondVar"]])

(and of course doing that you can also replace the string with a variable if your column name is unknown...)

Andrew Hill
  • 307
  • 2
  • 12