As Wikipedia says, “lint, or a linter, is a tool that analyses source code to flag programming errors, bugs, stylistic errors, and suspicious constructs.” In other words, linting is the process of standardising the format of how your code looks.
All written work has rules, either official or unofficial, about how it should be formatted. If you pick up and read a report you can expect a cover page, contents page, sections with headings in bold, page numbers, etc. Something like a thesis will additionally have chapters and appendices, and its bibliography will always follow the strict formatting rules of whichever referencing style it uses. In the same way, someone reading your code will have certain expectations about its format, and if your code is all over the place it will reduce its readability. This is why code style is important.
Trailing whitespace is superfluous:
# Bad:
print("Hello, World") ↵
# Good:
print("Hello, World")Lines should not be more than 80 characters:
# Bad:
print(ifelse(variable == 78, sprintf("This is a long line %s", variable), "Avoid this"))
# Good:
print(
ifelse(
variable == 78, sprintf("This is a long line %s", variable),
"But it is broken up so it is fine"
)
)Commented code should be removed:
# bad <- TRUE
good <- TRUEDo not place spaces around code in parentheses or square brackets:
# Bad:
print( "Hello, World" )
# Good:
print("Hello, World")Put spaces around all infix operators:
# Bad:
2+2
# Good:
2 + 2Use <- not = for assignment:
# Bad:
x = 2 + 2
# Good:
x <- 2 + 2Variable and function name style should be snake_case:
ThisIsBad <- 5
this_is_good <- 5In the old days, coders would use style guides (such as this one or this one or this one, and before the internet was what it is today the might even have used actual, physical books) in order to look up how to manually format their code. Fortunately, these days we have packages to do this for us, so take a look below:
This package will import an R script (or an R Markdown script that contains R code) and search it for style errors. Then it will tell you what they are so that you can fix them. To get it working do one of the following:
In RStudio:
install.packages("lintr") in the Consolesetwd() in the console to change to the folder where your script islint("<your_filename>.R>")In the Terminal:
R > run install.packages("lintr") > run q() to quitcd to move into the folder where your script isRlibrary(lintr)
lint("<your_filename>.R>")This will produce an output showing the linting errors in your file. Ideally, nothing will be produced. For more information see the docs.
You can bind this linting process to a keyboard shortcut in RStudio to make it as easy for yourself as possible:
lintr can be used with Sublime Linter for on-the-fly linting:
SublimeLinter using Package ControlsublimeLinter-contrib-lintr using Package Control. If this doesn’t work then do it manually:
Optionally, you can configure what linters are used or what specific linting rules are used. For example, you can have a different line length cutoff by changing the SublimeLinter User Settings to the following:
{
"user": {
"linters": {
"r": {
"linters": "with_defaults(line_length_linter(120))"
}
}
}
}This will take things one step further than the lintr package in that it will actually make the linting changes it suggests.
styler package in the same way as was detailed above for the lintr packagelintr package as well, although this time the R code to run is:library(styler)
input <- readLines("<your_filename>.R")
writeLines(style_text(input), con = "<your_filename>.R")This will import your script, lint it then export it to the same file (ie it will overwrite your script).