Привет всем. Сегодня у нас на тесте очередной проект Microsoft. По названию статьи можно догадаться, что в этот раз разработчики не смогли порадовать нас большим количеством ошибок. Надеемся, авторов проекта не обидит название. Ведь малое количество ошибок — это отлично, не правда ли? Тем не менее, кое-что интересное в коде Azure PowerShell всё же удалось найти. Предлагаем ознакомиться с особенностями этого проекта и взглянуть на ошибки, найденные с помощью C#-анализатора PVS-Studio.

Hello, everyone. Today we have another Microsoft project on the check. By the title of this article, you can guess that this time developers didn't «please» us with a large number of errors. We hope the project's authors won't be offended by the title. After all, a small number of errors is great, isn't it? However, we still managed to find something intriguing in the Azure PowerShell code. We suggest getting to know the features of this project and checking out errors, found using the PVS-Studio C# analyzer.

Эта статья о том, как однажды мы решили немного улучшить внутренний инструмент SelfTester, применяемый для проверки качества работы анализатора PVS-Studio. Улучшение было несложным и выглядело полезным, но создало нам много проблем, и впоследствии выяснилось, что лучше бы мы его не делали.

This article is the story how we once decided to improve our internal SelfTester tool that we apply to test the quality of the PVS-Studio analyzer. The improvement was simple and seemed to be useful, but got us into some troubles. Later it turned out that we'd better gave up the idea.

Мы любим искать ошибки в проектах Microsoft. Почему? Всё просто: их проекты, как правило, легко проверить (работу можно вести сразу в среде Visual Studio, для которой у PVS-Studio есть удобный плагин) и они содержат мало ошибок. Поэтому обычный алгоритм работы такой: найти и скачать открытый проект от MS; проверить его; выбрать интересные ошибки; убедиться, что их немного; написать статью, не забыв похвалить разработчиков. Великолепно! Win-win-win: времени ушло немного, руководство радо появлению новых материалов в блоге, да и карма в полном порядке. Но в этот раз что-то пошло не так. Давайте посмотрим, что интересного удалось найти в исходном коде Windows Forms и стоит ли хвалить Microsoft в этот раз.

We like to search for errors in Microsoft projects. Why? It's simple: their projects are usually easy to check (you can work in Visual Studio environment for which PVS-Studio has a convenient plugin) and they contain few errors. That's why the usual work algorithm is as follows: find and download an open source project from MS; check it; choose interesting errors; make sure there are few of them; write an article without forgetting to praise the developers. Great! Win-win-win: it took a little time, the bosses are glad to see new materials in the blog, and karma is fine. But this time «something went wrong». Let's see what we have found in the source code of Windows Forms and whether we should speak highly of Microsoft this time.

PVS-Studio is a tool for detecting software bugs and potential vulnerabilities in the source code of software written in C, C++, C#, and Java. The analyzer runs on Windows, Linux, and macOS.

Время от времени мы возвращаемся к проектам, которые уже проверяли ранее с помощью PVS-Studio и писали про это статьи. Делать это интересно по двум причинам. Во-первых, чтобы понять, насколько лучше стал наш анализатор. Во-вторых, чтобы отследить, обратили ли авторы проекта внимание на нашу статью, а также на отчет об ошибках, который мы им обычно предоставляем. Конечно, ошибки могут быть исправлены и без нашего участия. Но всегда приятно, когда именно наши усилия помогают сделать какой-то проект лучше. Не стал исключением и Roslyn. Предыдущая статья о проверке этого проекта датируется 23 декабря 2015 года. Это довольно давно, учитывая путь, который за это время проделал в своём развитии наш анализатор. Дополнительный интерес лично для нас Roslyn представляет ещё и тем, что на нём базируется ядро C# анализатора PVS-Studio. Таким образом, мы очень заинтересованы в качестве кода этого проекта. Устроим ему повторную проверку и выясним, что же нового и интересного (но будем надеяться, что ничего существенного) там сможет найти PVS-Studio.

Once in a while we go back to the projects that we have previously checked using PVS-Studio, which results in their descriptions in various articles. Two reasons make these comebacks exciting for us. Firstly, the opportunity to assess the progress of our analyzer. Secondly, monitoring the feedback of the project's authors to our article and the report of errors, which we usually provide them with. Of course, errors can be corrected without our participation. However, it is always nice when our efforts help to make a project better. Roslyn was no exception. The previous article about this project check dates back to December 23, 2015. It's quite a long time, in the view of the progress that our analyzer has made since that time. Since the C# core of the PVS-Studio analyzer is based on Roslyn, it gives us additional interest in this project. As a result, we're as keen as mustard about the code quality of this project. Now let's test it once again and find out some new and interesting issues (but let's hope that nothing significant) that PVS-Studio will be able to find.

Приветствую всех любителей покритиковать чужой код. :) Сегодня в нашей лаборатории новый материал для исследования — исходный код проекта AWS SDK для .NET. В своё время мы писали статью о проверке AWS SDK для C++. Тогда не нашлось ничего особо интересного. Посмотрим, чем нас порадует .NET версия AWS SDK. Хорошая возможность в очередной раз продемонстрировать возможности анализатора PVS-Studio, а также сделать мир немного совершеннее.

Welcome to all fans of trashing someone else's code. :) Today in our laboratory, we have a new material for a research — the source code of the AWS SDK for .NET project. At the time, we wrote an article about checking AWS SDK for C++. Then there was not anything particularly interesting. Let's see what .NET of the AWS SDK version is worth. Once again, it is a great opportunity to demonstrate the abilities of the PVS-Studio analyzer and make the world a bit better.

В последнее время мы усилили наше присутствие на различных профильных IT-конференциях в России и за рубежом. На большинстве мероприятий стараемся стоять со стендом, на некоторых выступаем с докладами. Конференции позволяют не только повысить узнаваемость нашего продукта (статический анализатор кода PVS-Studio), но и, главное, ближе познакомиться с потенциальными и действующими пользователями. Общаясь с посетителями на стенде, наши сотрудники часто отвечают на однотипные вопросы, которые иногда бывают довольно курьёзными. В данной статье я постараюсь ответить на наиболее часто задаваемые вопросы посетителей о статическом анализе вообще и PVS-Studio в частности.

Автоматизированные тесты пользовательских интерфейсов — тема, к которой настороженно относятся даже опытные разработчики. При этом технология такого тестирования не представляет собой чего-либо экстраординарного, а в случае Visual Studio Coded UI Tests является расширением встроенной системы модульного тестирования Visual Studio Team Test. В этой статье я хочу остановиться как на теме UI-тестирования в общем, так и на нашем частном опыте применения Visual Studio Coded UI Tests в работе над статическим анализатором PVS-Studio.

В конце мая (28 — 29) команда PVS-Studio посетила выставку «Российские интернет-технологии 2018» в качестве участника и спонсора. РИТ — масштабный фестиваль для интернет-разработчиков и просто неравнодушных людей. Мероприятие проходило в Кампусе Сколково («Московская школа управления»). В данной заметке я поделюсь своими ощущениями от посещения выставки.


Первое, что поразило при подъезде к Кампусу — архитектура здания. Или зданий, сразу как-то и не поймешь.

Недавно произошло долгожданное для многих событие — компания Unity Technologies разместила исходный C#-код игрового движка Unity для свободного скачивания на GitHub. Представлен код движка и редактора. Конечно, мы не могли пройти мимо, тем более, что в последнее время мы пишем не так много статей о проверке проектов на C#. Unity разрешает использовать предоставленные исходники только в справочных целях. Именно так и поступим. Испытаем последнюю на данный момент версию PVS-Studio 6.23 на коде Unity.

Сегодня мы отойдём от классического клише второсортных детективов и расскажем вам о случае из нашей практики, когда дворецкий сам выступил в роли жертвы, а поиски настоящего преступника привели нас к неожиданному результату. Но не стоит пугаться. Речь, конечно же, пойдет не о настоящих людях, а о программах. И о том, что нам не страшно признавать собственные ошибки: мы-то знаем, что от них не застрахован ни один коллектив разработчиков.

Сегодня я вновь возвращаюсь к проекту Tizen. В своей недавней заметке «Эксперимент по поиску ошибок в коде C# компонентов Tizen» в нашем блоге я провел поверхностный анализ и пришел к выводу, что имеет смысл проверить весь код C# компонентов этого проекта на наличие ошибок при помощи анализатора PVS-Studio и написать про это статью. Не откладывая в долгий ящик, я проделал эту работу и хочу поделиться с вами её результатами. Сразу скажу, что на C# коде анализатор PVS-Studio показал себя слабо. Однако обо всём по порядку: давайте посмотрим, что смог найти анализатор, а затем займёмся статистикой и подведём итоги.

Недавно я проводил сравнение C# анализаторов PVS-Studio и SonarQube на базе кода проекта PascalABC.NET. Исследование оказалось довольно интересным, поэтому я решил продолжить работу в данном направлении. В этот раз я сравниваю C# анализатор PVS-Studio со статическим анализатором, встроенным в Visual Studio. На мой взгляд, это весьма достойный соперник. Несмотря на то, что анализатор из комплекта Visual Studio, в первую очередь, рассчитан не на поиск ошибок, а на улучшение качества кода, это вовсе не означает, что с его помощью нельзя найти реальные ошибки, хотя это и трудно. Давайте разберемся, какие же особенности работы анализаторов будут выявлены в ходе нашего исследования на этот раз. Вперёд!

В ноябре прошлого года в нашем блоге была опубликована статья о разработке и использовании плагина PVS-Studio для SonarQube. Мы получили много откликов от клиентов и просто заинтересованных пользователей с просьбами провести тестирование плагина на реальном проекте. Так как интерес к этому вопросу не ослабевает, было решено провести тестирование на C# проекте PascalABC.NET. Также не будем забывать, что SonarQube содержит собственный статический анализатор C# кода — SonarC#. Для полноты картины проведем исследование и SonarC#. Целью данной работы является не сравнение анализаторов, а показ основных особенностей их взаимодействия с сервисом SonarQube. Прямое сравнение анализаторов было бы не вполне корректным по той причине, что PVS-Studio является специализированным инструментом поиска ошибок и потенциальных уязвимостей, в то время как SonarQube — это сервис оценки качества кода по большому числу параметров: дублирование кода, соблюдение стандартов кодирования, покрытие кода модульными тестами, возможные ошибки в коде, плотность комментариев в коде, технический долг и т.д.

Для оценки качества работы нашего анализатора, а также с целью популяризации методологии статического анализа, мы регулярно проверяем на наличие ошибок проекты с открытым исходным кодом и пишем про это статьи. Не стал исключением и прошедший 2016 год, который примечателен ещё и тем, что это было время своеобразного «взросления» C# анализатора. PVS-Studio получил значительное количество новых C# диагностик, улучшенный механизм работы с виртуальными значениями (symbolic execution) и многое другое. По результатам проделанной нашей командой работы, я составил своеобразный хит-парад наиболее интересных ошибок, обнаруженных в проектах С# в 2016 году.