Comments 8
Рефакторинг без контекста - корень всех бед.
А точно это не ошибка копипасты и теперь мы замели под ковёр пропуск какой-то важной опции при проверке? (хотя наверное неважной, если до сих пор не было замечено)
Именно поэтому рекомендуется использовать инструменты статического анализа непосредственно в процессе разработки. Пока разработчик "в контексте" и цена исправления ошибки минимальна.
Хотя, наверное, неважной, если до сих пор не было замечено
Кстати, вы обратили внимание на интересные момент. Действительно мы часто описываем ошибки, которые скорее всего слабо влияют на поведение программы (редкий сценарий). А всё почему? Потому что вот такие разовые проверки демонстрируют работу анализатора, но не являются правильным способом его использования. Те ошибки, которые сильно влияют на работу программы уже найдены, но с большой затратой энергии. Их находили при тестировании, в процессе отладки, благодаря письмам недовольных пользователей... А ведь многие из них можно было-бы найти статическим анализатором ещё на этапе написания кода.
Первая операция сравнения взводит некий механизм, вторая операция с той же константой производит выстрел. Где-то может быть перегружен оператор сравнения. 😁
Что тут неясного?
А вы всё испортили. 🙂
Всегда стараюсь оформлять код красиво, в едином стиле.
Когда попадается какая нить легаси, или рефакториь, чей то код, сначала форматирую его, если неотформатирован. И только потом можно приступать к изучению
А если сделать switch вместо if, то компилятор выдаст ошибку на одинаковые case.
Завершение цикла публикаций про TDengine - Необходимость статического анализа для РБПО на примере 190 багов в TDengine.
Учимся рефакторить код на примере багов в TDengine, часть 1: про колбасу