lintr lints are automatically displayed in the RStudio Markers pane, Rstudio versions (> v0.99.206).
Install lintr, type install.packages("lintr")
in the Console.
In order to show the "Markers" pane in RStudio: Menu "Tools" -> "Global Options...", a window with title "Options" will pop up. In that window: Click "Code" on the left; Click "Diagnostics" tab; check "Show diagnostics for R".
To lint a source file test.R
type in the Console lintr::lint("test.R")
and look at the result in the "Markers" pane.
This package also includes two addins for linting the current source and package. To bind the addin to a keyboard shortcut navigate to Tools > addins > Browse Addins > Keyboard Shortcuts. It's recommended to use Alt+Shift+L for linting the current source code and Ctrl+Shift+Alt+L to code the package. These are easy to remember as you are Alt+Shift+L(int) ;)
lintr has built-in integration with flycheck versions greater than 0.23
.
lintr is fully integrated into flycheck when using ESS. See the installalation documentation for those packages for more information.
You can also configure what linters are used. e.g. using a different line length cutoff.
M-x customize-option
->flycheck-lintr-linters
->with_defaults(line_length_linter(120))
lintr can be integrated with syntastic for on the fly linting.
Put the file syntastic/lintr.vim
in syntastic/syntax_checkers/r
. If you are using
pathogen this directory is
~/.vim/bundles/syntastic/syntax_checkers/r
.
You will also need to add the following lines to your .vimrc
.
let g:syntastic_enable_r_lintr_checker = 1
let g:syntastic_r_checkers = ['lintr']
You can also configure what linters are used. e.g. using a different line length cutoff.
let g:syntastic_r_lintr_linters = "with_defaults(line_length_linter(120))"
lintr can be integrated with Sublime Linter for on the fly linting.
Simply install sublimeLinter-contrib-lintr
using Package Control.
For more information see Sublime Linter Docs
You can also configure what linters are used. e.g. using a different line length cutoff. In the SublimeLinter User Settings
{
"user": {
"linters": {
"r": {
"linters": "with_defaults(line_length_linter(120))"
}
}
}
}
lintr can be integrated with Linter for on the fly linting.
Simply install linter-lintr
from within Atom or on the command line with:
apm install linter-lintr
For more information and bug reports see Atom linter-lintr.
Syntax errors
: reported by parse.object_usage_linter
: check that closures have the proper usage using codetools::checkUsage(). Note this runs base::eval() on the code, so do not use with untrusted code.absolute_path_linter
: check that no absolute paths are used (e.g. "/var", "C:\System", "~/docs").nonportable_path_linter
: check that file.path() is used to construct safe and portable paths.pipe_continuation_linter
: Check that each step in a pipeline is on a new line, or the entire pipe fits on one line.assignment_linter
: check that<-
is always used for assignmentclosed_curly_linter
: check that closed curly braces should always be on their own line unless they follow an else.commas_linter
: check that all commas are followed by spaces, but do not have spaces before them.extraction_operator_linter
: check that the[[
operator is used when extracting a single element from an object, not[
(subsetting) nor$
(interactive use).implicit_integer_linter
: check that integers are explicitly typed using the form1L
instead of1
.infix_spaces_linter
: check that all infix operators have spaces around them.line_length_linter
: check the line length of both comments and code is less than length.no_tab_linter
: check that only spaces are used, never tabs.object_length_linter
: check that function and variable names are not more thanlength
characters.object_name_linter
: check that object names conform to a single naming style, e.g. snake_case or lowerCamelCase.open_curly_linter
: check that opening curly braces are never on their own line and are always followed by a newline.semicolon_terminator_linter
: check that no semicolons terminate statements.single_quotes_linter
: check that only single quotes are used to delimit string contestants.spaces_inside_linter
: check that parentheses and square brackets do not have spaces directly inside them.spaces_left_parentheses_linter
: check that all left parentheses have a space before them unless they are in a function call.todo_comment_linter
: check that the source contains no TODO comments (case-insensitive).trailing_blank_lines_linter
: check there are no trailing blank lines.trailing_whitespace_linter
: check there are no trailing whitespace characters.T_and_F_symbol_linter
: avoid the symbolsT
andF
(forTRUE
andFALSE
).undesirable_function_linter
: report the use of undesirable functions, e.g.options
orsapply
and suggest an alternative.undesirable_operator_linter
: report the use of undesirable operators, e.g.:::
or<<-
and suggest an alternative.unneeded_concatenation_linter
: check that thec
function is not used without arguments nor with a single constant.
Lintr supports per-project configuration of the following fields.
The config file (default file name: .lintr
) is in Debian Control Field Format.
linters
- see?with_defaults
for example of specifying only a few non-default linters.exclusions
- a list of filenames to exclude from linting. You can use a named item to exclude only certain lines from a file.exclude
- a regex pattern for lines to exclude from linting. Default is "# nolint"exclude_start
- a regex pattern to start exclusion range. Default is "# nolint start"exclude_end
- a regex pattern to end exclusion range. Default is "# nolint end"
An example file that uses 120 character line lengths, excludes a couple of files and sets different default exclude regexs follows.
linters: with_defaults(line_length_linter(120))
exclusions: list("inst/doc/creating_linters.R" = 1, "inst/example/bad.R", "tests/testthat/exclusions-test")
exclude: "# Exclude Linting"
exclude_start: "# Begin Exclude Linting"
exclude_end: "# End Exclude Linting"
With the following command, you can create a configuration file for lintr
that ignores all linters that show at least one error:
library(magrittr)
library(dplyr)
lintr::lint_package() %>%
as.data.frame %>%
group_by(linter) %>%
tally(sort = TRUE) %$%
sprintf("linters: with_defaults(\n %s\n NULL\n )\n",
paste0(linter, " = NULL, # ", n, collapse="\n ")) %>%
cat(file = ".lintr")
The resulting configuration will contain each currently failing linter and the corresponding number of hits as a comment. Proceed by successively enabling linters, starting with those with the least number of hits. Note that this requires lintr
0.3.0.9001 or later.
If you want to run lintr
on Travis-CI you will need
to have travis install the package first. This can be done by adding the
following line to your .travis.yml
r_github_packages:
- jimhester/lintr
If you are already using testthat for
testing simply add the following to your tests to fail if there are any lints
in your project. You will have to add Suggests: lintr
to your package
DESCRIPTION
as well.
if (requireNamespace("lintr", quietly = TRUE)) {
context("lints")
test_that("Package Style", {
lintr::expect_lint_free()
})
}
If you do not want to fail the travis build on lints or do not use testthat you
can simply add the following to your .travis.yml
after_success:
- Rscript -e 'lintr::lint_package()'
In both cases the lintr-bot will add comments
to the commit or pull request with the lints found and they will also be
printed on Travis-CI or Wercker. If you want to disable the commenting you can
set the environment variable LINTR_COMMENT_BOT=false
.
To install the latest development version of lintr from GitHub
devtools::install_github("jimhester/lintr")
Most of the default linters are based on Hadley Wickham's R Style Guide.