Что плохого в множественном присваивании?

Question

[tostershmoster]

на такую замечательную строку кода

let observers : Function[] = presenter.view.changeSettingsObserver.observers = [];

eslint матюкается вот таким образом

Unexpected chained assignment. eslint no-multi-assign

Answer 1

[Alexandroppolus]

В eslint есть дохренища разных правил, которые кажутся странными. Например, запрет на операцию ++ и --. Или запрет менять что-то внутри объекта, на который ссылается аргумент текущей функции. Или, например, обязательное использование this в экземплярном методе класса (откровенно глупое требование).
В общем, напоминает американское законодательство с приколами вроде "не стрелять по кактусам со второго этажа".
Так что настраивай линтконфиг и не заморачивайся.

Comments

[Василий Банников]

В общем, напоминает американское законодательство с приколами вроде "не стрелять по кактусам со второго этажа".

Но при этом, раз такое правило есть - значит у его автора с этим когда-то произошла реальная проблема :)

[tostershmoster]

Василий Банников, так вот это и хотелось бы понять, что там за проблема с таким присваиванием

[Василий Банников]

tostershmoster, просто сложно читается, сложно понять что будет в результате, и что хотел автор такой строчки.

[Василий Банников]

tostershmoster, подробнее можете почитать в мануале: https://eslint.org/docs/rules/no-multi-assign#:~:t....

Answer 2

[Василий Банников]

Ну как минимум это очень неочевидная и трудночитаемая конструкция.
Любая неочевидная или трудночитаемая штука потенциально может привести к очень долго починяемым багам, потере морали в команде, массовым увольнениям из-за выгорания, и смерти проекта.

eslint матюкается вот таким образом

Лучше пусть eslint, чем коллеги.

Если для всех членов вашей команды очевидно, как работает такая конструкция, и вы не видите в ней проблем - переопределяйте правило.

Comments

[tostershmoster]

А что не очевидного в записи a = b = c = 10 ?

[Василий Банников]

tostershmoster, В каком порядке произойдёт присваивание => какие значения будут у каждой переменной.
А ещё это может быть опечатка.
Повторюсь: это не очевидно только для меня и для автора этого правила.
Если это очевидно для вас - просто выключайте его.

[Василий Банников]

tostershmoster,
Вот тут подробнее
https://eslint.org/docs/rules/no-multi-assign#:~:t....

[Alexandroppolus]

Василий Банников,

В каком порядке произойдёт присваивание

в стандарте прописано, что работает справа налево - т.е. присваивается в последнюю упомянутую переменную, потом в предпоследнюю и т.д.

[Василий Банников]

Alexandroppolus,

в стандарте прописано, что работает справа налево - т.е. присваивается в последнюю упомянутую переменную, потом в предпоследнюю и т.д.

В стандарте и поведение при складывании и сравнении разных типов присутствует, но тем не менее все используют ===.

Разработка - это не про использование всех возможных фичей языка для сжатия кода, но и про удобство дальнейшей поддержки.

Вот кто сможет гарантировать, что человек, который написал это:

let tmp = foo = bar;
if(tmp)
  doSomething();
else
  doAnother();
  doAnother2();

На самом деле хотел то, что написал?
А вот если запретить неочевидные штуки - всё становится очевидно.

this.foo = bar;
let tmp = bar;
if(tmp !== 0) {
  doSomething();
} else {
  doAnother();
  doAnother2();
}

[Alexandroppolus]

Василий Банников,

Вот кто сможет гарантировать, что человек, который написал это:
let tmp = foo = bar;
На самом деле хотел то, что написал?

с тем же успехом он может ошибиться, написав

foo = bar; // вместо this.foo = bar;
let tmp = bar;

[Василий Банников]

Alexandroppolus, ну вообще я хотел такой пример сделать: let tmp = foo === bar;
Но вообще чем более жёсткие правила, тем меньше способов ошибиться.
Для этого существует правило обязательной ';', для этого же существует правило с обязательными {}, строгим сравнением, множественным присваиванием, обязательным this