Linter rule prefer_adjacent_string_concatenation conflicts with no_adjacent_strings_in_list

Describe the issue
I have e.g. a very long string in a list, which I need to splite into separate parts (to avoid lines longer than 80 characters). If I try to do this using the + I'm receiving the prefer_adjacent_string_concatenation warning.

To Reproduce
The following code gives me a lint warning prefer_adjacent_string_concatenation.

final myList = [
  'very long string' +
    'continue very long string'
]

But doing this with the quick fix, I'm receiving no_adjacent_strings_in_list.

final myList = [
  'very long string' 
    'continue very long string'
]

Expected behavior
The linter won't raise the warning prefer_adjacent_string_concatenation in lists.

We may just want to document that these two rules conflict. Or we may want prefer_adjacent_string_concatenation to allow + in a list.

Maybe only allow it when no_adjacent_strings_in_list is enabled, and then document the interactions between the two lints?

@pq

I believe that the two rules satisfy good practices:

prefer_adjacent_string_concatenation is a style-oriented rule, but it is in the recommended set. So... it is recommended.
no_adjacent_strings_in_list is an error-preventing lint rule. When you write var x = ['a' 'b', 'c'];, the formatter will not change that text. Same with var x = [if (1 == 2) 'a' 'b', 'c'];. So the rule is designed to prevent bugs where a comma was accidentally omitted.

Because of that, I don't think the implementation of either rule should conflict with the other. We should not make users choose between one recommended practice and one safe practice.

I think as far as prefer_adjacent_string_concatenation goes, it should definitely allow addition (+) for strings in collection literals, to help prevent the bugs that no_adjacent_strings_in_list prevents.

@pq @bwilkerson

@lrhn

/fyi @lrhn @jakemac53 @munificent @natebosch @goderbauer (who may have interest since this is in the recommended set)

@bwilkerson

I'd do what @bwilkerson said above: allow + only if the no_adjacent_strings_in_list lint is enabled.

We should guarantee that the + is handled efficiently (behaves like adjacent string literals, not doing repeated runtime consternation).

When you write var x = ['a' 'b', 'c'];, the formatter will not change that text.

This is true of the current formatter, but the upcoming style will give you:

var x = [
  'a'
      'b',
  'c',
];

The new formatter always splits between adjacent strings.

Thanks, Bob!

Ok with that, I don't think we need to go through hoops to support no_adjacent_strings_in_list. It's not a recommended rule, and only targets (will only target) error-prone adjacent strings in non-formatted code. We can just declare the rules incompatible, in lieu of supporting "lint configuration based on what other lint rules are enabled."

linter: Declare that two adjacent-string-concerned rules are incompat…

Fixed with 6c5a9e4

Revert "linter: Declare that two adjacent-string-concerned rules are …

This fix was reverted; declaring two lint rules to be incompatible can break the flutter build.

Remove `no_adjacent_strings_in_list` from enabled lint rules. (#7878)

Remove `no_adjacent_strings_in_list` from enabled lint rules. (flutte…

Still reproducible on a local build of main (3.14.0-edge.17e7a7c8bdb3ecc5cfcdf15d39daf2bd0ae8b443) with both prefer_adjacent_string_concatenation and no_adjacent_strings_in_list enabled:

final myList1 = [
  'very long string' +
      'continue very long string', // prefer_adjacent_string_concatenation
];
final myList2 = [
  'very long string'
      'continue very long string', // no_adjacent_strings_in_list
];

Both forms are reported, so there is no lint-clean way to split a string inside a list literal. The earlier fix (declaring the rules incompatible, 6c5a9e4) was reverted. One option discussed above is to have prefer_adjacent_string_concatenation (pkg/linter/lib/src/rules/prefer_adjacent_string_concatenation.dart) skip + inside list/set literals.

Navigation Menu

Repository navigation

Linter rule prefer_adjacent_string_concatenation conflicts with no_adjacent_strings_in_list #59041

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Linter rule prefer_adjacent_string_concatenation conflicts with no_adjacent_strings_in_list #59041

Description

Activity

srawlins commented on Feb 16, 2023

bwilkerson commented on Feb 16, 2023

srawlins commented on Apr 18, 2024

pq commented on Apr 19, 2024

lrhn commented on Apr 19, 2024

munificent commented on Apr 27, 2024

srawlins commented on Apr 29, 2024

srawlins commented on Apr 29, 2024

srawlins commented on May 15, 2024

keertip commented on Oct 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions