A 'Linter' for R Code

Checks adherence to a given style, syntax errors and possible semantic issues. Supports on the fly checking of R code edited with 'RStudio IDE', 'Emacs', 'Vim', 'Sublime Text' and 'Atom'.

Travis-CI Build Status codecov.io CRAN_Status_Badge

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


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 integrated with Sublime Linter for on the fly linting.

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


lintr can be integrated with Linter for on the fly linting.

Atom Example


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.

Available linters

  • Syntax errors: reported by parse.
  • object_usage_linter: checks 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_paths_linter: checks that no absolute paths are used.
  • assignment_linter: checks that <- is always used for assignment
  • closed_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.
  • 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.
  • camel_case_linter: check that function and variable names are not camelCase.
  • snake_case_linter: check that function and variable names are not snake_case.
  • multiple_dots_linter: check that function and variable names are separated by _ rather than ..
  • object_length_linter: check that function and variable names are not more than length characters.
  • open_curly_linter: check that opening curly braces are never on their own line and are always followed by a newline.
  • single_quotes_linter: checks 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.
  • trailing_blank_lines_linter: check there are no trailing blank lines.
  • trailing_whitespace_linter: check there are no trailing whitespace characters.

Project Configuration

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:

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


lintr 1.0.3

  • Fix tests to work with changes in the parser in R 3.6

lintr 1.0.2

  • Fix tests to work with upcoming testthat release.

lintr 1.0.1

  • bugfix to work with knitr 1.16.7
  • expect_lint_free() now is always skipped on CRAN. This is necessary because the non-binary R source may not be available when running tests on CRAN, and those tests may not be run in the package directory.

lintr 1.0.0

  • bugfix to work with testthat 1.0.0

lintr 0.3.3

  • infix_spaces_linter now properly checks = in named arguments. (#130, @saurfang).
  • commas_linter now properly recognizes lints when preceded by a blank line and points to the missing space rather than the comma (#111, #129, @saurfang).
  • Make spaces_left_parentheses_linter more robust when determining ( type (#128, @saurfang)
  • commented_code_linter (#83, @jackwasey)
  • Now trims long comments (#55, reported by @paulstaab)
  • Automatic commenting of Github commits and pull requests when linting on Travis-CI
  • expect_lint_free expectation can be added to testthat unit tests.
  • Robust configuration system and exclusion logic
  • Emacs and Sublime Text 3 plugins now available from their respective package repositories.
  • add names.lints, split.lints (#49, @ttriche)
  • Fixed bug that caused vim syntatic plugin not to work properly in windows (#46, @abossenbroek)
  • allow lintr customization per project using .lintr config files.
  • use globalenv() instead of baseenv() for default parent environment so that methods will be included.
  • do not check object usage if eval fails. Fixes (#24, reported by @fabian-s)
  • trailing_whitespace_linter was reporting the incorrect line number
  • Use RStudio source marker API to display lints (#37, @jjallaire)
  • Permit single quotes if they quote literal double quotes (#28, @jackwasey)
  • # nolint comments are respected with caching (#68, @krlmlr)
  • Properly handle all knitr document formats

lintr 0.2.0

  • Initial release

Reference manual

It appears you don't have a PDF plugin for this browser. You can click here to download the reference manual.


2.0.1 by Jim Hester, 2 years ago


Report a bug at https://github.com/jimhester/lintr/issues

Browse source code at https://github.com/cran/lintr

Authors: Jim Hester [aut, cre] , Florent Angly [aut] , Russ Hyde [aut]

Documentation:   PDF Manual  

MIT + file LICENSE license

Imports rex, crayon, codetools, cyclocomp, testthat, digest, rstudioapi, httr, jsonlite, knitr, stats, utils, xml2, xmlparsedata

Suggests rmarkdown, mockery

Imported by adaptalint, autoharp, dupree, goodpractice, languageserver.

Suggested by BTYDplus, BiasCorrector, ConNEcT, DBItest, DIZutils, DataFakeR, DepthProc, DominoDataCapture, FSelectorRcpp, NHSRplotthedots, NLMR, OpenML, PWFSLSmoke, Plasmidprofiler, PosteriorBootstrap, RSQL, RestRserve, SamplerCompare, TDA, WikidataQueryServiceR, WoodburyMatrix, abbyyR, aws.alexa, babette, beautier, biolink, caretEnsemble, cattonum, cloudos, cmstatr, connectwidgets, crunch, dampack, dashboardthemes, dat, datarobot, datastructures, describer, devtools, diffusr, dittodb, edgarWebR, epigraphdb, fakemake, fst, fstcore, geofacet, geogrid, ggcharts, ggfortify, ggthemes, healthcareai, jpmesh, lifecycle, mlflow, mlr, mlrCPO, modules, newsmd, osfr, packager, pds3, physiology, pmpp, precommit, prettyB, rBiasCorrection, rasterpdf, rbokeh, rde, rdomains, requiRements, rnrfa, roadoi, scriptexec, secuTrialR, semantic.dashboard, shiny.info, shiny.react, shiny.semantic, smerc, stencilaschema, supernova, tsviz, tuber, urlshorteneR, virustotal, wavefunction, xgboost.

See at CRAN