Comments 16
Вы не думали о том чтобы создавать «рейтинг качественности кода», на регулярной основе?
Можете развить мысль? У нас есть некоторые идеи, но перед их озвучиванием хочется услышать мнение со стороны.
Он будет не очень честный. Те проекты, которые проверяются позже, могут получать всё более плохие оценки. Дело в том, что анализатор кода постоянно изменяется. Появляются новые диагностические предупреждения, улучшаются существующие. Нередко спустя год мы можем вновь написать статью о проверке проекта и там будут новые ошибки. Не только потому, что изменился проект, но и мы стали находить больше (см. обновляемый список open-source проектов, которые мы проверили с помощью PVS-Studio).
Ещё это не будет честно по причине, что проект меняется. Разработчики могу начать использовать статические анализаторы кода. Или мы проверили неудачную alpha-версию, а релизы у них намного стабильней.
Чтобы такой список был адекватен, все проекты надо время от времени перепроверять. А это уже постоянная работа для целого коллектива.
Ещё это не будет честно по причине, что проект меняется. Разработчики могу начать использовать статические анализаторы кода. Или мы проверили неудачную alpha-версию, а релизы у них намного стабильней.
Чтобы такой список был адекватен, все проекты надо время от времени перепроверять. А это уже постоянная работа для целого коллектива.
Так снова прогнать проверку.
Прогнать проверку легко. Вопрос, кто будет всем этим заниматься. Надо выкачивать проекты, менять для них окружение. Многие проекты ведь развиваются, меняют используемые библиотеки и так далее. Нужно анализировать результаты проверки. А потом эти результаты как-то оформлять и публиковать. Нет ведь смысла просто проверить и молчать в тряпочку :). А потом это всё надо повторить. А потом ещё раз и ещё… Финансировать кто это будет?
На самом деле, не всё так уж печально. У нас есть идея по полуавтоматической проверке некоторых наиболее интересных проектов и скажем еженедельном выкладывании отчётов. Однако, речь идёт только о нескольких отобранных проектах. Да и то всё это пока только рассуждения. Что-то поделать в эту сторону не хватает времени.
На самом деле, не всё так уж печально. У нас есть идея по полуавтоматической проверке некоторых наиболее интересных проектов и скажем еженедельном выкладывании отчётов. Однако, речь идёт только о нескольких отобранных проектах. Да и то всё это пока только рассуждения. Что-то поделать в эту сторону не хватает времени.
Самофинансирование за счет продаж по аналогии с dxomark.com
Ну в этом и идея. Рейтинг регулярный. К примеру ежегодный. Примерно как в экономике, переодически публикуются всякие индексы S&P и прочие. Т.е. идея заключается в том чтобы принудить разаработчиков наиболее популярных приложений конкурировать в этом рейтинге. С одной стороны это и вам выгодно, потому что они будут вынужденны пользоваться вашим инструментарием для проверки, и нам, пользователям, потому что мы будем получать более качесвенные програмные продукты. Ну и наконец это мотивирует вас постоянно добавлять новые проверки, чтобы не было такого что все программы прошли все тесты без единой ошибки )))
В очередной раз спасибо за интересную статью.
У меня есть идея относительно статей про PVS-Studio, быть может, она вам покажется небезынтересной. Сейчас наглядно показаны ошибки в кодах программ и делаются предположения, к каким негативным эффектам ошибки могут привести. Думаю, было бы круто увидеть эти негативные эффекты наглядно. Например: вот в коде известной программы такая ошибка, она в определенных случаях приводит к отображению некорректных данных (скриншот ошибочных данных), исправляем её — и вот программа работает правильно (скриншот верных данных).
Ясно, что полезной информации в иллюстрациях падений/неверной работы программ немного, но мне кажется психологически, это будет действовать сильнее: вот Chromium, который вы используете каждый день. А вот как в пару кликов все ломается (можете проверить у себя). Исправляем найденную с помощью PVS-Studio ошибку — и теперь ничего не падает.
У меня есть идея относительно статей про PVS-Studio, быть может, она вам покажется небезынтересной. Сейчас наглядно показаны ошибки в кодах программ и делаются предположения, к каким негативным эффектам ошибки могут привести. Думаю, было бы круто увидеть эти негативные эффекты наглядно. Например: вот в коде известной программы такая ошибка, она в определенных случаях приводит к отображению некорректных данных (скриншот ошибочных данных), исправляем её — и вот программа работает правильно (скриншот верных данных).
Ясно, что полезной информации в иллюстрациях падений/неверной работы программ немного, но мне кажется психологически, это будет действовать сильнее: вот Chromium, который вы используете каждый день. А вот как в пару кликов все ломается (можете проверить у себя). Исправляем найденную с помощью PVS-Studio ошибку — и теперь ничего не падает.
Да, мы думали над такими вещами. Однако, не доходят руки. Достаточно сложно в чужом коде понять, в каких ситуациях ошибка проявит себя. Например, касательно этой статьи, я вообще не представляю, как заставить программу попасть, скажем в ветку «if (memcmp(stopSgn, answer, sizeof(stopSgn) != 0))». У меня и микроскопа то нет. :)
Теперь серьезно. Многие ошибки находятся в редко используемых участках кода, например, в обработчиках нестандартных ситуаций. Поэтому и добраться до них сложно. А ошибки, появившиеся в часто используемом коде, уже исправлены к моменту проверки. При регулярном анализе, думаю такие ошибки можно обнаруживать и красиво демонстрировать. К сожалению, это может сделать только сам разработчик.
Впрочем, спасибо что напомнили про эту идею. Надо будет как ни будь при проверке простого проекта с разлапистым GUI попробовать «проявить» одну из ошибок, чтобы можно было сделать скриншот. Спасибо.
Теперь серьезно. Многие ошибки находятся в редко используемых участках кода, например, в обработчиках нестандартных ситуаций. Поэтому и добраться до них сложно. А ошибки, появившиеся в часто используемом коде, уже исправлены к моменту проверки. При регулярном анализе, думаю такие ошибки можно обнаруживать и красиво демонстрировать. К сожалению, это может сделать только сам разработчик.
Впрочем, спасибо что напомнили про эту идею. Надо будет как ни будь при проверке простого проекта с разлапистым GUI попробовать «проявить» одну из ошибок, чтобы можно было сделать скриншот. Спасибо.
А вы не пробовали проверять исходный код языков программирования? Например PHP или Ruby? Я хоть сам и не C/C++ разработчик, но было бы очень интересно почитать о таком (особенно о PHP)
Кое-что проверяли. Но такие проекты достаточно качественные и сложно написать статью. Обычно проверка заканчивалась тихим письмом разработчикам о паре подозрительных мест.
Вот, например, я отписывал разработчикам языка D. Как видите, статью из этого не сделаешь. Впрочем, это стало поводом к совместной статье с Уолтером Брайтом (создатель языка D): Язык D спешит на помощь.
Из статей, можно наверное назвать только проверку Clang: 1, 2.
Вот, например, я отписывал разработчикам языка D. Как видите, статью из этого не сделаешь. Впрочем, это стало поводом к совместной статье с Уолтером Брайтом (создатель языка D): Язык D спешит на помощь.
Из статей, можно наверное назвать только проверку Clang: 1, 2.
А как насчет проверок Mesa, LibreOffice, Blender и Gimp?
Blender. Остальное пока не проверяли.
P.S. Вот здесь можно смотреть, что мы проверили: Обновляемый список open-source проектов, которые мы проверили с помощью PVS-Studio.
P.S. Вот здесь можно смотреть, что мы проверили: Обновляемый список open-source проектов, которые мы проверили с помощью PVS-Studio.
Вот честно, когда прочитал название статьи, подумал что речь идеть о науке. Оказалось что просто балаболия о качестве кода
Sign up to leave a comment.
Единорог заинтересовался микромиром