Комментарии 10
Совсем не понял посыла — в битовом сдвиге, как и в некоторых других операциях, левый и правый операнды не являются взаимозаменяемыми. Утверждение "нет смысла сдвигать число само на себя" в общем случае не верно, ведь нет смысла только сдвигать число на 0 бит в любую сторону. (При этом 1 << 1 будет 2).
Срабатывание на 1 << 10, 1 << 1, 1 << 12 полезно, но в контексте шаблона разорванной последновательности одинаковых операций. Представленное правило и в этом случае срабатывает неверно (1 << 1 всё ещё равно 2).
Было бы правильней ввести список [бинарных] операций, к которым это правило было бы применимо или наоборот неприменимо.
Спасибо за вашу точку зрения!
Под “нет смысла сдвигать число само на себя” я имел в виду, что сходу сложно придумать, для чего это делать. Легко обосновать рутинные вещи вроде foo + foo или foo * foo, где вряд ли кроется какая либо ошибка. Именно поэтому, к ним это правило не применяется, как вы и описали.
Мне же показалось, что случай с foo << foo ближе к foo - foo (всегда получаем ноль), чем к foo * foo (возведение в квадрат). Если у вас есть соображение, почему не стоит считать такую операцию подозрительной, то мне было бы интересно узнать.
Потому что это не сдвиг "само на себя" - это сдвиг единицы на один бит. По вашей логике и возведение тройки в третью степень должно считаться подозрительной операцией, а возведение тройки в квадрат - нет.
Возможно, мы где-то друг друга не поняли :)
Ни я ни правило не считаем возведение в какую бы то ни было степень подозрительным, буквально за счёт вышеупомянутого списка применимых бинарных операций. Что до пресловутой единицы, то что 1 << 1, что foo << foo, это сдвиг операнда на самого себя, так что правило на это реагирует, покуда битовые сдвиги также присутствуют в этом списке. Точнее реагировало, до описанного в статье исключения с единицами.
Мне кажется Вам надо отдохнуть и взглянуть свежим взглядом) К этой статье 100 % комментаторов говорят что 1 << 1 - это НЕ сдвиг на самого себя - это две абсолютно разные константы. Если бы в коде было написано X << X - это ещё бы можно было заподозрить. А вы рассматриваете паттерн:
1 << ONE_BIT_CONST,
1 << TWO_BIT_CONST ...
100% на выборке в двух это мощно :) А так мы и правда, кажется, говорим на разных языках. С точки зрения синтаксического дерева, 1 << 1 это бинарная операция над двумя литералами, с одинаковым значением (единица). Это именно то, что ищет диагностика - два операнда идентичного типа и наполнения. 1 << TWO_BIT_CONST она не посмотрит, даже если значение у TWO_BIT_CONST внезапно будет 1.
100% на выборке в двух это мощно :)
Некоторые проголосовали за коммент - прибавьте (а остальные молча согласились 😁).
бинарная операция над двумя литералами, с одинаковым значением (единица).
Так и в ней нет ничего подозрительного, не менее подозрительно чем 1 << 2.
И почему, тогда не подозрительно что в последовательности
applyWorkingColorSpaces: 1 << 2,
emitHalftones: 1 << 3,
emitPostScriptXObjects: 1 << 4,
одну и ту-же единицу то на 2, то на 3 бита двигают? А где-то ниже эту-же самую единицу куда-то прибавляют, а там в сдвигах использовали? Это вообще warning as error (сарказм))
Вот если бы было написано
define x = 1
x << x
тогда - да, на саму себя, сдвиг был бы. А
Если (x << x) и очень подозрительная операция (хотя контексты когда она может иметь смысл есть, но это уже codegolf; то (1 << ?) – абсолютно валидная операция. даже если “?” – единица. даже так же операция (x << 2) валидная операция для любого x из диапазона [0,3] – втч и 2<<2. то же самоес (x<<3) для диапазона [0,7], включая 3<<3. думаю, идея понятна.
конкретно в примере должна быть ругань на suppressCropClip то только о том, что дубликат в енуме – но никак не на “1<<1”.
Да, всё так. Диагностика реагирует на синтаксическую эквивалентность операндов, поэтому сдвиги 2 << x, где x равен двум (и т.п.), не считаются подозрительными.
К выводу я пришёл тому же, посему срабатывания в анализаторе сейчас здесь нет. Чуть попозже, думаю, добавим как раз отдельную диагностику на битовые флаги.
Ошибка в коде, на которую приходится не обращать внимание