Комментарии 10
Динамическая типизация тут ни при чем. Хранить версию в виде строки можно и в java и в C.
PVS-Studio умеет отлавливать такие "ошибки"?
Отвечу цитатой из текста выше:
Вы можете смело сказать: "В заголовке сказано, что тесты упали из-за JavaScript, но ведь такое могло быть и в любом другом, даже статически типизированном языке!"— и будете правы. Однако конкретно в JavaScript мы можем найти причину довольно похожих происшествий.
Дело здесь действительно и не в JavaScript, и не в типизации. Но зайдя на поле одной известной ошибки, не мог обойти стороной и другие важные вопросы, касающиеся напрямую JavaScript.
Не понимаю ироничных кавычек у слова "ошибка". Это серьёзный дефект в программном обеспечении, который может привести к серьёзным проблемам.
В PVS-Studio (для C, C++, C# или Java) у нас пока нет подобных диагностических правил, но мы отложили идею в копилку. Отмечу, что у нас есть множество других правил, которые можно посмотреть на этой странице.
Непонятно, к чему вся эта драматическая история про тесты, если все сводится ровно к "мы тупо сравнили строки, не учитывая их специфики". При чем тут вообще js? А в каком другом языке есть встроенный тип "несколько целых через точку"?
Решением этой проблемы могло бы стать хранение версии в объекте, а не в строке:
interface VSCodeVersion { major: Number, minor: Number}А ничо тот факт, что у вас там номер версии из 3х чисел? И вообще-то это банальные массивы интов - которые и нужно сравнивать как таковые
Хранить версию в строке, это нормально. Потому что будут всякие alpha, релиз-кандидаты и прочие версии, например "1.0.0rc".
Но можно вполне сравнивать версии имея их список, и смотреть между какими версиями находится текущая в списке. Простой и дешёвый вариант. Можно ещё заняться разложением на объект и там уже магию строки принять к последнему элементу.
Непонятно, к чему вся эта драматическая история про тесты, если все сводится ровно к "мы тупо сравнили строки, не учитывая их специфики".
Драматическая история про тесты — реальный опыт, которым принято делиться в сообществе разработчиков, вы так не считаете?
Отмечу, что ошибка, про которую вы написали, была не в нашем коде, а во внешнем инструменте. Также мы написали о том, как разработчики этого инструмента её пофиксили.
При чем тут вообще js? А в каком другом языке есть встроенный тип "несколько целых через точку"?
Код, в котором произошла проблема, написан на JavaScript. И в тексте есть прямое указание на то, что подобная проблема может произойти и в любом другом языке. JavaScript посвящён следующий пункт, в котором рассматриваются другие интересные моменты, которые могут возникнуть при сравнении объектов непосредственно в JavaScript. И история про тесты важна, к тому же она является некоторым трамплином к специфичной для JavaScript теме.
Типы для сравнения строк в популярных языках действительно трудно найти, но есть инструменты, которые предоставляют подобный инструментарий. В WinAPI есть возможность для сравнения строк, например. Для JS/TS в тексте упомянута решающая проблему библиотека, к которой и прибегли разработчики фреймворка.
А ничо тот факт, что у вас там номер версии из 3х чисел? И вообще-то это банальные массивы интов - которые и нужно сравнивать как таковые
Окак…
Я предложил один из вариантов. Конечно, не могу вам запрещать использовать массив в таком случае. В моём представлении решение проблемы через небольшой объект будет лучше с точки зрения читаемости кода.
Два числа в объекте версии из-за того, что Visual Studio Code (про который и была речь) третьим числом в версии всегда имеет 0, и в этом контексте его можно смело пропустить.
в тексте есть прямое указание на то, что подобная проблема может произойти и в любом другом языке.
Но в заголовке прямо обвинен именно js. Пинать js за неявное и неочевидное новичку приведение типов, конечно, очень модно и весело, но в данном случае даже оно не при делах.
Для JS/TS в тексте упомянута решающая проблему библиотека, к которой и прибегли разработчики фреймворка
Описанная "проблема" не стоит выеденного яйца. Функция, корректно сравнивающая строки с учётом специфики формата, пишется на js в пару строк.
решение проблемы через небольшой объект будет лучше с точки зрения читаемости кода.
Не будет. Такой формат с точками семантически означает именно массив убывающих по значимости "слогов" (числовых ли, числоподобных ли, с буквами или без - это уж как захотите) в общем случае произвольной длины. Объект с двумя полями - это высосанное из пальца ограничение, ломающееся в вашем же собственном примере.
Признаться в такой ошибке это равносильно сказать, извините но эту задачу мы мы отдали самому младшему джуну, а сеньора за ним приглядывать не нашлось
Блин! Всегда считал PVS-Studio серьезной компанией, где работают настоящие профессионалы. И тут такой разочаровывающий заголовок!
Ваши тесты упали по причине JavaScript