Less aggressive linting

@eitsupi

Is your feature request related to a problem? Please describe.

The default linter (based on the tiydverse style guide IIRC) is too aggressive IMO. Users get low-key scolded for simple and acceptable actions like using = for assignment or the use of single quotation marks.

While users can edit their ~/.lintr files to change these settings locally, I do think we can be less aggressive out of the gate. ~~I see some linter settings have already been disabled here.~~ Correction: As @eitsupi correctly points out, the linked .lintr file is just relevant for this repo itself (i.e., the dev experience) and does not affect the end-user’s linting behaviour when running the extension.

Describe the solution you'd like

Here's what my own .lintr file looks like:

linters: linters_with_defaults(
   line_length_linter    = NULL, # note: vscode-R default is 120
   cyclocomp_linter      = NULL, # same as vscode-R
   object_name_linter    = NULL, # same as vscode-R
   object_usage_linter   = NULL, # same as vscode-R
   commented_code_linter = NULL,
   assignment_linter     = NULL,
   seq_linter.           = NULL,
   no_tab_linter.        = NULL,
   semicolon_linter      = NULL,
   single_quotes_linter  = NULL
)

I don't want to suggest that all of my choices should become the default, but I do think some are probably a good idea (e.g., the aforementioned assignment_linter and single_quotes_linter).

Describe alternatives you've considered

Add a wiki page on linting. (Can still do in conjunction, but again I think we should permit certain behaviour out of the gate.)

While users can edit their ~/.lintr files to change these settings locally, I do think we can be less aggressive out of the gate. I see some linter settings have already been disabled here.

Aren't these settings for R files in this repository and irrelevant to extension users?

@eitsupi

@eitsupi I think @grantmcdermott is referring to the defaulting linting options set by the extension, which lives in <vscode directory>/extensions/reditorsupport.r-2.8.2/R/.lintr and is used when no lintr file exists in the user or project directory.

@mkoohafkan

@mkoohafkan My understanding is that that file is never used for users.
I think this is just a configuration file used for linting in this repository.

Ah you're right, my mistake. Where does the extension get its default linting settings then? I can't find any other lint files in the VSCode directory (except for the Python extension, but that's unrelated).

Please check https://lintr.r-lib.org/

In other words, there is nothing peculiar to this extension. This is the default configuration for the lintr package

@eitsupi

@eitsupi VSCode is linting automatically though, users don't have the choice to "opt in" to linting (or opt out). Is the lintr package installed through language server or some other mechanism? To be clear, I never chose to install the lintr package---the extension does linting without any user input.

@mkoohafkan

@mkoohafkan I think it's more reliable to search within the documentation than to ask me.
https://lintr.r-lib.org/articles/editors.html#visual-studio-code

@eitsupi

@eitsupi ok so the answer is yes, languageserver adds linting automatically and just uses the defaults from the lintr package. This is confusing to users because they have no way of controlling the linting rules through the extension or even toggling R linting on/off via VSCode.

Perhaps the solution here is to have an option in settings to enable/disable linting. Users would then have the option to:

Enable/Disable R linting globally via user settings
Enable/Disable R linting per project via project settings
Customize linting by learning about the {lintr} package and creating their own .lintr files.

Just spending 30 minutes trying to turn off the annoying lining message after installing this extension.

For people who are also trying to figure it out, the .lintr setting showed in this issue doesn't work for me. This works:

linters: linters_with_defaults(
   line_length_linter    = NULL, # note: vscode-R default is 120
   cyclocomp_linter      = NULL, # same as vscode-R
   object_name_linter    = NULL, # same as vscode-R
   object_usage_linter   = NULL, # same as vscode-R
   commented_code_linter = NULL,
   assignment_linter     = NULL,
   seq_linter           = NULL,
   semicolon_linter      = NULL)

@eitsupi

@eitsupi

In other words, there is nothing peculiar to this extension. This is the default configuration for the lintr package

Barring that, it looks like a VScode issue -- as noted they already ship a non-default `line_length_linter()`, so they should be willing to ship non-defaults for other linters too. It looks like that default config is here:

https://github.com/REditorSupport/vscode-R/blob/b196c7d8257a04509de68a3bfe7acf9c1f2fba85/R/.lintr#L2

Originally posted by @MichaelChirico in r-lib/lintr#2592 (comment)

If there are already edits to the default lintr package settings there should be no problem with editing the default behavior in the vscode R package extension.

Hello. Just to add that I've tried many, many times, and no configuration in the .lintr file on <vscode directory>/extensions/reditorsupport.r-2.8.2/R/.lintr or ~\.lintr seems to work. Unfortunately, after many hours, I had to disable lsp.r.enabled. Frustrating.
Please, fix this.

I knowwww 😭 the documentation isn't very explicit, in my pr I've made sure to point out that it is in your home directory that you need to add the .lintr file, but I'm sure working with folders/workspaces is still vague and counterintuitive, once the PR is approved I'm thinking on making a more detailed guide on how to configure the extension for different workspaces.

Just spending 30 minutes trying to turn off the annoying lining message after installing this extension.

For people who are also trying to figure it out, the .lintr setting showed in this issue doesn't work for me. This works:
linters: linters_with_defaults(
   line_length_linter    = NULL, # note: vscode-R default is 120
   cyclocomp_linter      = NULL, # same as vscode-R
   object_name_linter    = NULL, # same as vscode-R
   object_usage_linter   = NULL, # same as vscode-R
   commented_code_linter = NULL,
   assignment_linter     = NULL,
   seq_linter           = NULL,
   semicolon_linter      = NULL)

Super useful, worked for me, thank you. Because we live in a strange world where R-Studio and Tidyverse don't appear to conform to the default indent standard in R, I would suggest making the addition of:
indentation_linter = NULL

Closing, since this issue doesn't seems to be getting traction from the vscode-R devs and the upstream lintr team are unlikely to change their defaults either.

FWIW, there's a dedicated linting wiki page now that covers most of the examples suggested in this thread. Hopefully, this will suffice for showing others how to implement a less heavy-handed linting policy...

I might follow r-lib/lintr#1177 as part of a way forward here -- exposing a way to easily control the config directly in lint* should make it easier for downstream consumers to be explicit about the config too.

Part of the issue is that today it's only possible to get the config detected implicitly according to 'some rules' which could be making things complicated for an IDE setup.

Example given in wiki https://github.com/REditorSupport/vscode-R/wiki/Code-linting for "Only detect syntax errors:"

linters: list()

does not seem to work for zed.dev, does it work for VS-code?

edit:

exclusions: list(".")

seems to work

Navigation Menu

Repository navigation

Less aggressive linting #1400

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Less aggressive linting #1400

Description

Activity

eitsupi commented on Aug 7, 2023

mkoohafkan commented on Dec 21, 2023

eitsupi commented on Dec 22, 2023

mkoohafkan commented on Dec 22, 2023

eitsupi commented on Dec 22, 2023

eitsupi commented on Dec 22, 2023

mkoohafkan commented on Dec 22, 2023

eitsupi commented on Dec 22, 2023

mkoohafkan commented on Dec 22, 2023

albert-ying commented on May 19, 2024

Jacinto27 commented on Jun 5, 2024

castellco commented on Jul 4, 2024

Jacinto27 commented on Jul 4, 2024

PD-LUHC commented on Sep 5, 2024

grantmcdermott commented on Feb 19, 2025

MichaelChirico commented on Feb 20, 2025

jangorecki commented on Jun 26, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions