Pull to refresh

Comments 58

UFO just landed and posted this here
PVS-Studio лицензируется на команду разработчиков. Нет цены «для одного разработчика» :). Как вариант, для индивидуальных проектов можно воспользоваться одним из бесплатных вариантов лицензирования (вариант 1, вариант 2).
UFO just landed and posted this here
Таки как раз в человека, который этим будет заниматься, я верю слабо.
Потому что тупые вещи пропускаются на ура.
PVS-Studio ROI: как не терять миллионы.
Аннотация
Время от времени нам задают вопрос, какую пользу в денежном эквиваленте получит компания от использования анализатора PVS-Studio. Я решил реализовать на сайте ROI-калькулятор и разместить подробное описание принципов его работы. Но прежде я решил вынести свои мысли и расчёты на обсуждение. Я надеюсь получить интересные и полезные комментарии, которые помогут сделать калькулятор как можно более достоверным и убедительным.
UFO just landed and posted this here
Да, PVS-Studio не ориентирован на маленькие низкооплачиваемые команды и арифметика не сходится. В Германии, например, средний заработок программистов: 56 – 93 тыс. евро в год и арифметика сходится. Всё OK :)
UFO just landed and posted this here
В России есть много взрослых компаний с взрослыми зарплатами. И количество российских клиентов уверенно растёт.

Давайте вообще всех толковых людей из страны выгоним, что уж… мало ведь их уже уехало и ещё видимо уедет.

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

Потому что переехать в большой город по тем или иным причинам невозможно?
Согласитесь правда, что PVS-Studio здесь не виноват? :-)
UFO just landed and posted this here
Рабочий день программиста с 8 утра?
Зачем работать в таких неадекватных конторах?

С 9 до 18 — принципиально лучше?

Если говорить о принципиально лучших вариантах, то это будет что-то навроде «восьмичасовой рабочий день, начало рабочего дня в диапазоне 8-12, по согласованию с непосредственным руководителем».
Я работаю с 7 до 16, и меня это вполне устраивает. Да и руководство, PM и остальной персонал, находящийся в Челябинске, тоже (в то время, как я в Питере).
Есть много положительных моментов работать в таком графике. Точнее это мои субъективные положительные моменты. Если будет интересно — я с вами ими поделюсь.

PS речь в этой статье не об этом. Не будем «офф-топить».
Серьёзно? Рабочий день с 8 утра — и ты в 17 уже свободен. Можно провести время с семьёй, например. Если бы я жил поближе к работе, то вообще бы с 7 утра работал.
Не все жаворонки. Среди программеров не мало сов.
UFO just landed and posted this here
Часов в сутках от этого не прибавится, раньше проснулся — раньше отошёл ко сну.
Крутой прогресс. Хотя я и не пишу ни на одном из поддерживаемых языков, но с удовольствием читаю многие ваши статьи, в меру своего понимания C++. Как насчёт также публиковать англоязычные статьи на хабре, раз они у вас уже есть?
Так уже же. Я выставил в настройках хабра английский язык и у меня появляется статья на английском.image
P.S. Судя по комментарию выше — это отдельная статья, а не потому, что я язык поставил английский.
Самое важное в Java анализаторе то, что он появился

Молодцы, поздравляю! Надеюсь, это откроет перед вами огромный рынок и сделает вашу компанию еще успешнее.

А не планировали для OpenSource проектов сделать интеграцию с GitHub для автоматического анализа и добавления результатов анализа в PR?
Ну или что-то типа такого Code Quality: Java?

Иногда в проектах используются собственные реализации разных системных функций, например, memcpy, malloc и т.п.… Теперь с помощью аннотации V_FUNC_ALIAS вы можете ставить имена своих функций в соответствие системным.

Либо я не понял фразу, либо какая-то гелогичность. Первое предложение звучит так, как будто в проекте может быть функция, называющаяся так же как системная, но делающая что-то другое (или делающая то же, но имеющая отличающуюся семантику). А оказывается наоборот — для системной функуии просто ввели другое название.

В проектах есть самописные функции, которые ведут себя с точки зрения использования, точно также, как memcpy, malloc, но реализован особенным образом.
А не планируете сделать как-нибудь так, чтоб отчеты можно было сравнивать? Чтоб было можно быстро найти новую появившуюся ошибку, имея два отчета?
Пожалуйста, расскажите про сценарий использования. Для чего это нужно?

И почему, не подходит массовое подавление сообщений анализатора (отключение выдачи предупреждений на существующий код). Которое как раз позволяет видеть только новые срабатывания.
например в CI системе найти список новых ошибок в комите и запостить в code review
На самом деле, у нас есть внутренние инструменты для «сравнения отчётов», мы их используем, например, в регрессионных тестах. Тем не менее, для конечного пользователя они, скорее всего, окажутся неудобными. Ведь при сравнении результатов работы анализатора, между получением которых прошло какое-то время, нужно учитывать, что проверяемый код мог правиться, в проверяемые файлы добавлялся код, из-за которого старый проверяемый код мог «съехать» и т.п. Поэтому, сравнение двух отчётов «в лоб» обычно неэффективно.

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

Мы также предоставляем утилиты для рассылки писем с результатами анализа, для преобразования результатов в различные форматы и т.п., так что вставить результат в code review отчёт также не должно быть трудно.
Для случая когда проверка интегрирована в билд. Я не придумал, как автоматизировать подавление сообщений в этом случае.
Я вот попробовал банально отсортировать отчет по файлам, номерам ошибок и номеру строки, после чего отчеты замечательно сравниваются любым диффом. Непонятно, почему по умолчанию отчет не только не отсортирован, а вообще рандомизирован (при каждом запуске разная последовательность сообщений).
Я примерно так и думал. Не планируете добавить сортер для отчетов?
Если про Visual Studio к примеру говорим, то там надо по столбцу кликнуть. Если про plog-converter, то там тоже можно сортировать по-разному.
О, plog-converter сортирует? Пошел смотреть…
plog-converter сам не сортирует. Но так как он идет в исходниках его можно заставить делать это именно так, как это нужно в данном проекте.
Как правило нет цели «сравнивать отчеты». Есть цель видеть новые ошибки. Этот механизм существует. Чтобы дать конкретные ссылки опишите свой сценарий использования.
Сценарий — проверка интегрирована в билд (около двух десятков проектов различной величины). Формируется отчет по каждому, формируется краткий отчет, из которого берутся цифры и сравниваются с эталоном (или с предыдущим билдом). Если предупреждений стало больше, нужно с этим что-то сделать. Хотелось бы вместо «загрузить эталонный отчет, выбрать суппресс алл, запустить проверку на текущих исходниках (т.к. если просто открыть новый отчет, на него не действует суппресс!), повторить два десятка раз» сразу получить отчет с новыми предупреждениями.
И про стркопи, раз уж всплыло — а если собственная реализация, к примеру, использует в качестве третьего параметра количество символов, а не количество байт, то как избавиться от предупреждения? Поможет аннотация?
Если собственная реализация использует в качестве третьего параметра количество элементов, а не количество байт, то это не memcpy, а совсем другая функция. И её размечать её как memcpy нельзя, так как это приведёт к ложным срабатываниям.

Для описанного случая, сейчас у нас ничего нет. Никто и не спрашивал. Становитесь клиентом, сделаем :).
Так вроде уже полгода как стали :) А про strcpy — вот есть две функции, strcpy и wcscpy, у первой единица измерения — char, у второй — wide char. И есть библиотека ACE (досталась в наследство, увы), которая эти две функции прячет под одним именем ACE_OS::strcpy() в зависимости от платформы и т.п. И у нее параметр — символ, либо одинарный, либо двойной… Пока пришлось это предупреждение выключить…
Александр, привет. Давай в почте продолжим. А то на Хабре, да с интервалом в два месяца не конструктивно обсуждать хотелки :-).
Да, написал в почту. Я просто пропустил ответ тут и только сейчас его увидел :)
Скачал, начал устанавливать и "C:\Program Files (x86)\PVS-Studio"… WTF???
Утилита которая началась давным давно с проверок переносимого года с 32-х на 64 бита сама до сих пор является 32-хбитной…
Ну во первых, наш продукт нельзя назвать чисто «32-битным» или «64-битным» — если говорить конкретно про Windows дистрибутив, то в него входит много разных утилит, некоторые из них (были) в том-числе 32-битными. Постепенно 32-битных утилит становится меньше, например наш C++ анализатор присутствовал в дистрибутиве как в виде 32-битной, так и 64-битной версий (сейчас от 32-битной версии мы отказались).

Во вторых, в папку Program Files (x86) он ставится, т.к. сам наш Windows инсталятор является 32-битным — можно сказать, что так исторически сложилось. В более старых версиях PVS-Studio, когда мы поддерживали старые IDE, такие как, например, Visual Studio 2008, возможно (я точно не ручаюсь, т.к. уже не помню), установка плагинов к таким IDE накладывала ограничения на создание чисто-64битного установщика. Также, PVS-Studio можно было установить и на 32-битную версию Windows (как я писал выше, сейчас это уже не актуально).

Так что, резюмируя, сам инсталятор, скорее всего, уже можно сделать 64-битным (возможно, мы это сделаем в будущем), однако на данный момент 32-битность инсталятора не создаёт для нас или наших пользователей каких-либо проблем, поэтому мы не видим это критичной задачей.
Хочу акцентировать еще раз внимание присутсвующих. Сам анализатор 64-битный и использует это на полную :-).
Да какая разница какой он, если свою работу выполняет? Комментарий был из разряда "занимательные факты".
Есть ли сравнение с уже существующими анализаторами из java мира? На сколько ваш лучше/хуже?
Sign up to leave a comment.