Публикации по теме 'static-code-analysis'


Полезные улучшения в версии PVS-Studio 6.17
Сегодня мы выпустили новую версию статического анализатора PVS-Studio 6.17. В этой версии есть улучшения, которые, на мой взгляд, заслуживают небольшого упоминания. Предлагаю ознакомиться с ними, а затем скачать последнюю версию дистрибутива. Мы продолжаем развивать наш анализатор применительно к Linux. Иными словами, версия анализатора для Linux по своим возможностям опережает версию анализатора для Windows. Следующим шагом стала реализация плагина для системы контроля качества..
Как статические анализаторы борются с ложными срабатываниями и почему они это делают
В своей предыдущей статье я писал, что мне не нравится подход к оценке эффективности статических анализаторов с помощью синтетических тестов. В этой статье я привожу пример фрагмента кода, который анализатор рассматривает как частный случай и намеренно не выдает предупреждения. Честно говоря, не ожидал такого количества комментариев по поводу того, что анализатор может не выдавать предупреждения из-за механизмов исключения ложных срабатываний. В целом тема борьбы с ложными срабатываниями..
Анализ проектов Unity: в файле решения есть два проекта с именами «UnityEngine.UI».
Пока PVS-Studio анализирует проект Unity, можно наткнуться на такую ​​ошибку: Произошла ошибка при попытке открыть файл решения «…»: В файле решения есть два проекта с именами «UnityEngine.UI». В этой заметке обсуждаются причины этой ошибки и способы ее устранения. Причины PVS-Studio использует некоторые сторонние библиотеки, включая Roslyn и MSBuild, для проверки C#-проектов. Мы используем Roslyn для разбора кода. MSBuild анализирует файлы решения (.sln) и проекта (.csproj). Кроме..
Ошибки, которые статический анализ кода не находит, потому что он не используется
Читатели наших статей иногда отмечают, что статический анализатор кода PVS-Studio выявляет большое количество ошибок, незначительных и не влияющих на работу приложения. Это действительно так. По большей части важные ошибки уже исправлены благодаря ручному тестированию, отзывам пользователей и другим дорогостоящим методам. При этом многие из этих ошибок можно было найти еще на этапе написания кода и исправить с минимальными потерями времени, репутации и денег. В этой статье будет приведено..
Бесконечный цикл борьбы с ошибками программирования.
Программисты — забавные существа. Сначала они изобрели строго типизированные языки программирования, чтобы компиляторы могли автоматически обнаруживать больше ошибок в программах. Затем компьютеры стали быстрее, и это позволяет программистам переходить на слаботипизированные языки программирования. Эти языки потребляют больше вычислительных ресурсов, но программисты говорят, что это ускоряет их работу. Программистам теперь не нужно возиться с проектированием и описанием изящной..
Есть ли у вашего приложения React Native ЗАПАХ ?
React и React Native — отличные фреймворки для быстрой разработки! Но за это приходится платить: JavaScript . JavaScript — отличный язык. Но тот факт, что он настолько вседозволен, дает вам возможность делать абсолютно все, что вы хотите, и так, как вы хотите. Вы можете подумать, что быть свободным — это хорошо. Конечно, у этого есть некоторые преимущества, но оказывается, что вы можете захотеть наложить на себя некоторые ограничения, если вы не хотите полностью потерять контроль,..
Статический анализ кода в монорепозитории — NodeJS + React
Монорепо — это (хорошая|плохая) стратегия? Честно говоря, мне все равно. Но я понял, что часто использую его при разработке проектов NodeJS+React. Когда я выполняю автоматический статический анализ кода в монорепозитории, всегда возникают две основные проблемы: покрытие и шаблоны кода. Что касается охвата, то ответ довольно прост: Codacy позволяет создавать частичные отчеты как для бэкенда, так и для фронтенда. Это задокументировано здесь и выглядит примерно так: ➜ ~..