Build Status CRAN version

Static code analysis for R




lintr lints are automatically displayed in the RStudio Marker pane, Rstudio versions (> v0.99.206). RStudio Example


lintr has built-in integration with flycheck versions greater than 0.23. Emacs Example


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.

Vim Example

Vim Example


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 = 1


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))"

Sublime Text 3

lintr can be intergrated with Sublime Linter for on the fly linting.

Sublime Example

Sublime Example


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))"

Available linters

Project Configuration

Lintr supports per-project configuration of the following fields. The config file (default file name: .lintr) is in Debian Control Field Format.

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:

lintr::lint_package() %>% %>%
  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 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

  - 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)) {
  test_that("Package Style", {

Non-failing Lints

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

  - 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.

Installation of develment version

To install the latest development version of lintr from GitHub



Most of the default linters are based on Hadley Wickham's R Style Guide.