Linter should suggest having a space on either side of any binary operators, and before any unary operators

[Hixie]

This code shows why you might care:

void main() {
  print(5 ~/ 10); // prints the result of integer divining five by ten
  print(5 /~ 10); // prints the result of dividing five by the bitwise-complement of ten
  int x = 10;
  x += 1; // adds one to x
  x =+ 1; // sets x to one
}

With the suggested lint, the following code would be ok:

void main() {
  print(5 ~/ 10);
  print(5 / ~10);
  int x = 10;
  x += 1;
  x = +1;
}

[zoechi]

Shouldn't this be handled by dartfmt?

[pq]

Shouldn't this be handled by dartfmt?

In general, yes. However, some folks don't use it. (Specifically, flutter.)

[pq]

FWIW this bit

x =+ 1; // sets x to one

produces a warning ("expected an identifier"). Maybe it didn't before?

@Hixie : is the intent here to make it more obvious when someone intends a binary op but is getting a unary one? Typing, for example, 5 /~ 10 when they meant 5 ~/ 10?

[bwilkerson]

The code x =+ 1; produces an error because + is not a valid prefix operator.

[Hixie]

is the intent here to make it more obvious when someone intends a binary op but is getting a unary one? Typing, for example, 5 /~ 10 when they meant 5 ~/ 10?

That was in fact the exact case that led to my filing this bug.

Regarding =+, change all my examples from using + to using -.

[pq]

Update: the lint as described in 1fdc9f9 caused enough confusion (namely around the overlapping roles of the formatter and analyzer) that we've decided to back it out pending more consideration. Along those lines, @bwilkerson had some interesting thoughts around focusing on the particular mistakes (e.g., ~/ vs. /~) rather than more generally linting something ensured by the formatter.

Sidenote: this further emphasizes the value in finding a happy place where the formatter plays nice with (in this case Flutter) idiomatic Dart. Luckily, folks are working on just that. 👍

[srawlins]

Just my 2c: I think we'd be much more productive to let dartfmt make rules about whitespace, and linter make rules about anything but whitespace. It would be a real waste to get into the whitespace game int the linter...

[Hixie]

some of us can't use the formatter because it is too opinionated, but still want to avoid bugs like this one.

[zoechi]

A simplified formatter that doesn't change line-breaks, similar to how it works in IntelliJ with TypeScript would probably provide more value than linter rules.

[Hixie]

If we had a formatter that didn't mess up expressions like:

  if (offset.x == velocity.x * xFactor + x0 &&
      offset.y == velocity.y           + xy)
    return true;

...then sign me up. Until then, a linter can solve the problem described in the OP in a way a formatter can't.

(see https://github.com/dart-lang/dart_style/issues/530, https://github.com/dart-lang/dart_style/issues/531, https://github.com/dart-lang/dart_style/issues/528, https://github.com/dart-lang/dart_style/issues/525, or my personal favourite, https://github.com/dart-lang/dart_style/issues/452)

[zoechi]

@Hixie I guess in this case I'm in favor of linter rules as well :D