Судьба Отчета Об Ошибке

Довольно распространенный (и логичный) вопрос для наших статей о проверке open-source проектов: отправляются ли отчеты об ошибках разработчикам? Итак, ответ — да.

Более того, мы не останавливаемся на достигнутом и иногда отслеживаем прогресс.

Сегодня мне бы хотелось рассказать об одном из случаев, когда именно эта педантичность помешала фиктивному исправлению ошибки.

Введение

Ведь всем нравится, когда программы работают быстро, корректно и стабильно.

Другое дело, что не всех интересует, что происходит с их отчетами об ошибках после их отправки.

А зря, ведь уделив совсем немного внимания, вы можете значительно ускорить решение проблемы или даже помочь исправить больше, чем было задумано изначально.

Вот о чем я говорю.

Пару месяцев назад мы опубликовали статью с проверка проекта Chromium , в рамках которого я отправил разработчикам отчет об ошибке с ошибками из статьи.

Но, как вы понимаете, если бы все было хорошо, то эта заметка не увидела бы свет. Что пошло не так?

Важная оговорка: Баги свойственны всем, и к разработчикам Chromium у меня нет претензий.

Просто наткнулся на интересный случай, который можно привести в качестве примера :)

Несмотря на то бесконечный огромный список открытых проблем, мой отчет обработали практически в тот же день и даже включили исправление.

Бывает совершенно по-другому .

Перед началом не помешает освежить память об ошибке, о которой пойдет речь далее (случай N8 из оригинальная статья ): В501 Слева и справа от '||' имеются идентичные подвыражения 'file.MatchesExtension(L".

xlsb").

оператор.

download_type_util.cc 60

   

 ClientDownloadRequest::DownloadType GetDownloadType(const base::FilePath& file)
 {
   .


   if (file.MatchesExtension(FILE_PATH_LITERAL(".

apk")))
     return ClientDownloadRequest::ANDROID_APK;
   .


   else if (file.MatchesExtension(FILE_PATH_LITERAL(".

pdf")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

doc")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

docx")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

docm")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

docb")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

dot")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

dotm")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

dotx")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

xls")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

xlsb")) ||    // <=
            file.MatchesExtension(FILE_PATH_LITERAL(".

xlt")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

xlm")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

xlsx")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

xldm")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

xltx")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

xltm")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

xlsb")) ||    // <=
            file.MatchesExtension(FILE_PATH_LITERAL(".

xla")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

xlam")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

xll")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

xlw")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

ppt")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

pot")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

pps")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

pptx")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

pptm")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

potx")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

potm")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

ppam")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

ppsx")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

ppsm")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

sldx")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

xldm")) ||
            file.MatchesExtension(FILE_PATH_LITERAL(".

rtf")))
     return ClientDownloadRequest::DOCUMENT;
   .


 }

   

Перейдем к делу

Хм.

Всего за один день? Любопытство взяло верх, и я решил посмотреть, что там происходит. И не зря.

Здесь произошло именно то, о чем меня предупреждали коллеги: описывая одну из ошибок, я решил не раскрывать полностью описываемую проблему и оставил некоторую часть читателям для самостоятельной работы.

В результате исправление, внесенное разработчиками, выделено красным, а желтым я выделил еще одно повторяющееся значение, которое должен был найти сам.

Такое ощущение, что разработчики немного поторопились с внесением изменений в код и не внимательно прочитали статью.

Обидно, придется учитывать это на будущее.

Конечно, я сразу написал разработчики отметили, что на внесенное изменение следует обратить особое внимание, и указали на дополнительное значение, которое следует проверить/удалить.

Ну, теперь это ошибка исправлено правильно , а можно ещё немного подискутировать на тему, можно ли было вообще избежать такой проблемы? С одной стороны, у разработчиков Chromium и так достаточно работы, и за внимательное чтение чужих статей в поисках дополнительных проблем им, скорее всего, не доплачивают. С другой стороны, качество кода все равно страдает. В приведенном выше примере довольно сложно найти ошибку, даже зная, что она точно есть.

Эх, если бы был способ как-то отлавливать такие ошибки.

Но подождите, он есть! Я не уверен насчет классических проверок кода (ведь этот код был включен в репозиторий), но большинство статических анализаторов вполне справились бы с этим случаем.

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

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

Возможно, я не упомянул какие-то другие варианты.

Тогда буду рад услышать ваше мнение по этому поводу в комментариях.

Кстати, подобный случай с проверкой проекта у нас уже был.

КовидСим .

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

Об этом и еще одном подобном случае вы можете прочитать в статьях моего коллеги» Как PVS-Studio защищает от необдуманных правок кода " И " Как PVS-Studio защищает от необдуманных правок кода, пример N2 ".

Ну и напоследок хотелось бы узнать, следите ли вы за дальнейшей судьбой своих багрепортов?

Дополнительные ссылки

• Как PVS-Studio защищает от необдуманных правок кода .

• Как внедрить статический анализатор кода в устаревший проект, не демотивируя команду .

• Философия статического анализа кода: у нас 100 программистов, анализатор нашел мало ошибок, бесполезно ли это?

Приключение отчета об ошибке .

В опросе могут участвовать только зарегистрированные пользователи.

Войти , Пожалуйста.

Следите ли вы за будущими отчетами об ошибках? 82,76% Да, я следую за 24 17,24% Нет, моя работа - просто отправить 5, проголосовало 29 пользователей.

8 пользователей воздержались.

Теги: #Google Chrome #с открытым исходным кодом #C++ #Chromium #pvs-studio #статический анализ кода #статический анализ

• Все О Нетбуке Lenovo S10-3T 0651-37U

  19 Oct, 24

• Зеленый Каталог: Признание Экологии В Интернете

  19 Oct, 24

• «Азиатские Тигры»: Особенности Корпоративной Культуры Японцев, Китайцев И Вьетнамцев

  19 Oct, 24

• Терминальный Сервер Для Autocad

  19 Oct, 24

• Идея Языка Программирования Искусственного Интеллекта. Имущественно-Ориентированный Подход

  19 Oct, 24

• Обзор Основных Функций Citrix Netscaler

  19 Oct, 24

• Четыре Слова, Которые Ты Не Можешь (Часть 2)

  19 Oct, 24

• Сколько Ваших Собственных Веб-Сайтов/Проектов/Сервисов Полностью Созданы Вами?

  19 Oct, 24

• Восстание Машин: Как Роботы Взяли На Себя Бухгалтерский Учет

  19 Oct, 24

• Izoho – Набор Онлайн-Офисных Инструментов Для Apple Iphone

  19 Oct, 24