Вы можете смело сказать: "В заголовке сказано, что тесты упали из-за JavaScript, но ведь такое могло быть и в любом другом, даже статически типизированном языке!"— и будете правы. Однако конкретно в JavaScript мы можем найти причину довольно похожих происшествий.
Дело здесь действительно и не в JavaScript, и не в типизации. Но зайдя на поле одной известной ошибки, не мог обойти стороной и другие важные вопросы, касающиеся напрямую JavaScript.
Не понимаю ироничных кавычек у слова "ошибка". Это серьёзный дефект в программном обеспечении, который может привести к серьёзным проблемам.
В PVS-Studio (для C, C++, C# или Java) у нас пока нет подобных диагностических правил, но мы отложили идею в копилку. Отмечу, что у нас есть множество других правил, которые можно посмотреть на этой странице.
Непонятно, к чему вся эта драматическая история про тесты, если все сводится ровно к "мы тупо сравнили строки, не учитывая их специфики".
Драматическая история про тесты — реальный опыт, которым принято делиться в сообществе разработчиков, вы так не считаете?
Отмечу, что ошибка, про которую вы написали, была не в нашем коде, а во внешнем инструменте. Также мы написали о том, как разработчики этого инструмента её пофиксили.
При чем тут вообще js? А в каком другом языке есть встроенный тип "несколько целых через точку"?
Код, в котором произошла проблема, написан на JavaScript. И в тексте есть прямое указание на то, что подобная проблема может произойти и в любом другом языке. JavaScript посвящён следующий пункт, в котором рассматриваются другие интересные моменты, которые могут возникнуть при сравнении объектов непосредственно в JavaScript. И история про тесты важна, к тому же она является некоторым трамплином к специфичной для JavaScript теме.
Типы для сравнения строк в популярных языках действительно трудно найти, но есть инструменты, которые предоставляют подобный инструментарий. В WinAPI есть возможность для сравнения строк, например. Для JS/TS в тексте упомянута решающая проблему библиотека, к которой и прибегли разработчики фреймворка.
А ничо тот факт, что у вас там номер версии из 3х чисел? И вообще-то это банальные массивы интов - которые и нужно сравнивать как таковые
Окак…
Я предложил один из вариантов. Конечно, не могу вам запрещать использовать массив в таком случае. В моём представлении решение проблемы через небольшой объект будет лучше с точки зрения читаемости кода.
Два числа в объекте версии из-за того, что Visual Studio Code (про который и была речь) третьим числом в версии всегда имеет 0, и в этом контексте его можно смело пропустить.
Да, override на этом методе действительно есть, и все другие реализации уже не допускают того же, на что указало срабатывание в статье. Но зачем в исходной реализации параметр перетирается? Выглядит как не самое хорошее решение, потому в статью и попало. Кстати, помимо этого, у данного метода даже есть две реализации, которые похожи как две капли воды :)
В общем, скорее всего нам стоило вынести это срабатывание анализатора в раздел про чистоту кода, поскольку это определённо не прям-таки баг. Но мне кажется, что как указатель на странные решения в ООП дизайне, это срабатывание вполне имеет право на жизнь. Это буквально "Человек, задумайся!" от анализатора.
Точную вероятность сказать не смогу (выше тоже был комментарий с таким запросом :), но мне кажется, что в разбитом на классы switch разработчику проще заметить, если что-то написано не так. Но, опять же, это imho и попытка высчитать общую температуру по палате
В статье по той ссылке действительно был пересказ спора с моими комментариями, но также была и вторая часть с, что называется, размышлениями на тему.
Насчёт "огромности" switch согласен, что с точки зрения code review иерархия классов будет не лучшей альтернативой. Но мне всё же кажется, что в процессе написания кода при правильной декомпозиции можно просто глазами заметить ошибку. Но это, полагаю, imho
Спасибо за комментарий! Про "Программист-прагматик" действительно упустил. Книга давно стоит на полке и ждёт, никак не соберусь с мыслями, чтобы посвятить ей достаточно времени)
Насчёт подхода к статическому анализу дополню, что не стоит отключать диагностики просто для того, чтобы спрятать то, что он находит. Если вы хотите выключить диагностику на этапе внедрения, это вполне может быть оправдано. Например, нет смысла включать диагностические правила стандартов MISRA, если вы не разрабатываете ПО в соответствии с этими стандартами :)
Спасибо за ваше мнение! Должен отметить, что в данной статье приведена несколько субъективная подборка событий, происходивших в языке (авторы такие авторы...). Моё внимание было направлено на приведённый в статье список изменений по той же причине, по которой для Вас важна унификация представления отрицательных целых - у каждого разработчика свои потребности :) Да и для упоминания всех изменений всех стандартов правильнее было бы писать статью про каждый из них, чем проводить общую экскурсию по истории языков.
Нет, предыдущие срабатывания не останутся, поскольку анализатор будет проводить анализ только для изменённых файлов. Но перед запуском анализа плагин предложит сохранить отчёт. Однако, в будущем релизе PVS-Studio 7.35 в Visual Studio будет добавлен режим анализа модифицированных файлов (в данном тексте описан для PVS-Studio_Cmd.exe), который будет также проверять, не исправлены ли выданные ранее предупреждения.
MSBuild сохраняет информацию о том, какие файлы обновлялись в .tlog файлы и на основе этих файлов умеет пересобирать только то, что имеет более новую временную метку. На основе этого же механизма анализатор понимает, какие файлы были изменены, а какие нет. Поэтому нет, после повторной сборки без изменений файлы не будут modified.
Отвечу цитатой из текста выше:
Дело здесь действительно и не в JavaScript, и не в типизации. Но зайдя на поле одной известной ошибки, не мог обойти стороной и другие важные вопросы, касающиеся напрямую JavaScript.
Не понимаю ироничных кавычек у слова "ошибка". Это серьёзный дефект в программном обеспечении, который может привести к серьёзным проблемам.
В PVS-Studio (для C, C++, C# или Java) у нас пока нет подобных диагностических правил, но мы отложили идею в копилку. Отмечу, что у нас есть множество других правил, которые можно посмотреть на этой странице.
Драматическая история про тесты — реальный опыт, которым принято делиться в сообществе разработчиков, вы так не считаете?
Отмечу, что ошибка, про которую вы написали, была не в нашем коде, а во внешнем инструменте. Также мы написали о том, как разработчики этого инструмента её пофиксили.
Код, в котором произошла проблема, написан на JavaScript. И в тексте есть прямое указание на то, что подобная проблема может произойти и в любом другом языке. JavaScript посвящён следующий пункт, в котором рассматриваются другие интересные моменты, которые могут возникнуть при сравнении объектов непосредственно в JavaScript. И история про тесты важна, к тому же она является некоторым трамплином к специфичной для JavaScript теме.
Типы для сравнения строк в популярных языках действительно трудно найти, но есть инструменты, которые предоставляют подобный инструментарий. В WinAPI есть возможность для сравнения строк, например. Для JS/TS в тексте упомянута решающая проблему библиотека, к которой и прибегли разработчики фреймворка.
Окак…
Я предложил один из вариантов. Конечно, не могу вам запрещать использовать массив в таком случае. В моём представлении решение проблемы через небольшой объект будет лучше с точки зрения читаемости кода.
Два числа в объекте версии из-за того, что Visual Studio Code (про который и была речь) третьим числом в версии всегда имеет 0, и в этом контексте его можно смело пропустить.
Для проектов на GitVerse можно также написать нам, и мы выдадим лицензию
Да,
overrideна этом методе действительно есть, и все другие реализации уже не допускают того же, на что указало срабатывание в статье. Но зачем в исходной реализации параметр перетирается? Выглядит как не самое хорошее решение, потому в статью и попало. Кстати, помимо этого, у данного метода даже есть две реализации, которые похожи как две капли воды :)В общем, скорее всего нам стоило вынести это срабатывание анализатора в раздел про чистоту кода, поскольку это определённо не прям-таки баг. Но мне кажется, что как указатель на странные решения в ООП дизайне, это срабатывание вполне имеет право на жизнь. Это буквально "Человек, задумайся!" от анализатора.
Точную вероятность сказать не смогу (выше тоже был комментарий с таким запросом :), но мне кажется, что в разбитом на классы
switchразработчику проще заметить, если что-то написано не так. Но, опять же, это imho и попытка высчитать общую температуру по палатеСпасибо за комментарий!
В статье по той ссылке действительно был пересказ спора с моими комментариями, но также была и вторая часть с, что называется, размышлениями на тему.
Насчёт "огромности"
switchсогласен, что с точки зрения code review иерархия классов будет не лучшей альтернативой. Но мне всё же кажется, что в процессе написания кода при правильной декомпозиции можно просто глазами заметить ошибку. Но это, полагаю, imhoСпасибо за комментарий! Про "Программист-прагматик" действительно упустил. Книга давно стоит на полке и ждёт, никак не соберусь с мыслями, чтобы посвятить ей достаточно времени)
Насчёт подхода к статическому анализу дополню, что не стоит отключать диагностики просто для того, чтобы спрятать то, что он находит. Если вы хотите выключить диагностику на этапе внедрения, это вполне может быть оправдано. Например, нет смысла включать диагностические правила стандартов MISRA, если вы не разрабатываете ПО в соответствии с этими стандартами :)
Спасибо за комментарий!
Спасибо!
Спасибо!
Спасибо за ваше мнение!
Должен отметить, что в данной статье приведена несколько субъективная подборка событий, происходивших в языке (авторы такие авторы...). Моё внимание было направлено на приведённый в статье список изменений по той же причине, по которой для Вас важна унификация представления отрицательных целых - у каждого разработчика свои потребности :)
Да и для упоминания всех изменений всех стандартов правильнее было бы писать статью про каждый из них, чем проводить общую экскурсию по истории языков.
Нет, предыдущие срабатывания не останутся, поскольку анализатор будет проводить анализ только для изменённых файлов. Но перед запуском анализа плагин предложит сохранить отчёт.
Однако, в будущем релизе PVS-Studio 7.35 в Visual Studio будет добавлен режим анализа модифицированных файлов (в данном тексте описан для
PVS-Studio_Cmd.exe), который будет также проверять, не исправлены ли выданные ранее предупреждения.MSBuild сохраняет информацию о том, какие файлы обновлялись в
.tlogфайлы и на основе этих файлов умеет пересобирать только то, что имеет более новую временную метку. На основе этого же механизма анализатор понимает, какие файлы были изменены, а какие нет.Поэтому нет, после повторной сборки без изменений файлы не будут modified.
Спасибо за комментарий! В том числе для этого текста некоторые детали были подчёркнуты из этой книги, а во второй части будет целый пункт про неё :)
Вторая часть статьи уже вышла! Приятного чтения!
Да, в репозитории проекта открыл Issue, в котором написал о найденных ошибках