# nolint next special comment

[jmbarbone]

Is there any interest in using a # nolint next special comment to be applied to the next line of code?

Current special comments can look kind of intrusive and awkward for some lines. Using a next comment may look and feel a bit more natural.

# nolint

# nolint: line_length_linter. Lorem ipsum dolor sit amet, ornare ex et himenaeos aenean commodo auctor accumsan gravida.

MyFunctionName <- function( # nolint: object_name_linter.
    a = 1,
    b = 2
) {
  a + b
}

# nolint start ... end

# nolint start: line_length_linter.
# Lorem ipsum dolor sit amet, ornare ex et himenaeos aenean commodo auctor accumsan gravida.
# nolint end: line_length_linter.

# nolint start: object_name_linter.
MyFunctionName <- function( 
    # nolint end: object_name_linter.
    a = 1,
    b = 2
) {
  a + b
}

# nolint next

# nolint next: line_length_linter.
# Lorem ipsum dolor sit amet, ornare ex et himenaeos aenean commodo auctor accumsan gravida.

# nolint next: object_name_linter.
MyFunctionName <- function( 
    a = 1,
    b = 2
) {
  a + b
}

I'd be happy enough with a next line only implementation, but it might open up a possible request of # nolint next 5.

[AshesITR]

Out of curiosity, are there other linters / code analysis tools that provide such a feature?
I haven't seen it before.

Also NB in your example, you'll also want to add a . after the linters to be suppressed even if there is no following comment.

[jmbarbone]

pylint has disable-next, which is basically the same thing.

# pylint: disable-next=unbalanced-tuple-unpacking
a, b = ...

Attributes in Rust can suppress the native linters and behave in a similar way:

fn used_function() {}

// `#[allow(dead_code)]` is an attribute that disables the `dead_code` lint
#[allow(dead_code)]
fn unused_function() {}

fn noisy_unused_function() {}
// FIXME ^ Add an attribute to suppress the warning

fn main() {
    used_function();
}

Not sure about the . in examples though, they run fine:

reprex

lintr::lint("
# nolint: line_length_linter. Lorem ipsum dolor sit amet, ornare ex et himenaeos aenean commodo auctor accumsan gravida.

MyFunctionName <- function( # nolint: object_name_linter
    a = 1,
    b = 2
) {
  a + b
}
")

lintr::lint("
# nolint start: line_length_linter
# Lorem ipsum dolor sit amet, ornare ex et himenaeos aenean commodo auctor accumsan gravida.
# nolint end: line_length_linter

# nolint start: object_name_linter
MyFunctionName <- function( 
    # nolint end: object_name_linter
    a = 1,
    b = 2
) {
  a + b
}
")

^{Created on 2022-12-04 with reprex v2.0.2}

[AshesITR]

Not sure about the . in examples though, they run fine:

That's because they parse as unqualified # nolint directives, suppressing all lints and not just the intended lint.

[MichaelChirico]

I think it's a great idea. It's especially a pain if a # nolint comment induces a line_length_linter() hit.

API-wise, I think we'll do well to avoid having both # nolint and # nolint next since the first matches the second. Is # nolint-next the best choice (only distinguished from # nolint by the subsequent - instead of or :?

[AshesITR]

We already have # nolint start clashing, so I wouldn't mind # nolint next.

[MichaelChirico]

We already have # nolint start clashing, so I wouldn't mind # nolint next.

I have a PR basically done implementing this (posting soon). One difference of the clash of # nolint start vs # nolint next is that the former applies to the current line while the latter doesn't.

That makes something like this:

x<-1 # nolint: infix_spaces_linter. # nolint next: assignment_linter.
y = 2

Harder to handle than something like this:

x<-1 # nolint: infix_spaces_linter. # nolint start: assignment_linter.
y = 2
z = 3 # nolint end

(I think it's not particularly relevant in practice, so I'll proceed by ignoring this situation)