Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
☑︎ FindBugs не использую, зашёл посмотреть, что это такое
Плагин для maven заведется, если ему зависимость поменять или ждать новой версии?
Мавен постараемся обновить на днях.
Выложил 3.0.1 в централ:
repo1.maven.org/maven2/com/google/code/findbugs/findbugs/3.0.1/
Попробуйте поменять зависимость.
repo1.maven.org/maven2/com/google/code/findbugs/findbugs/3.0.1/
Попробуйте поменять зависимость.
Сработало. Держите фидбэк:
При использовании вот такого singleton-а у метода getInstance() может быть побочный эффект: при первом его вызове будет вызван конструктор. Поэтому формально ругаться на вызов getInstance() без присвоения как на RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT неправильно. С другой стороны, необходимость в ленивом синглтоне в этом случае (при том, что мы явно просим его инициализироваться в определенный момент), конечно, под вопросом.
При использовании вот такого singleton-а у метода getInstance() может быть побочный эффект: при первом его вызове будет вызван конструктор. Поэтому формально ругаться на вызов getInstance() без присвоения как на RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT неправильно. С другой стороны, необходимость в ленивом синглтоне в этом случае (при том, что мы явно просим его инициализироваться в определенный момент), конечно, под вопросом.
Да, вызов с целью инициализации — одна из основных причин ложных срабатываний. В описании бага это написано. Ну и да, вызов геттера для инициализации, конечно, подозрителен. Но всё же кое-какие шаги я делал, чтобы уменьшить число таких проблем. Если можно, покажите конкретный код, где происходит ложное срабатывание (уменьшите его по возможности).
Jenkins описание бага не показал, кстати:
Как-то так: pastebin.com/XEp6xjE6
У нас я порешал проблему удалением принудительной инициализации, но не факт, что всем это подойдет.
Return value of ModuleRegistry.getInstance() ignored, but method has no side effect
No description available.
Как-то так: pastebin.com/XEp6xjE6
У нас я порешал проблему удалением принудительной инициализации, но не факт, что всем это подойдет.
Спасибо, поразбираюсь. Была идея как раз подобные случаи отлавливать. Что-то пошло не так.
Jenkins-плагин мы не поддерживаем. Возможно, стоит сообщить разработчикам. Вообще прикол в том, что если запускать findbugs в режиме xml:withMessages, то полные описания багов вываливаются прямо в результирующую xml-ку (в тегах BugPattern). Но Jenkins, похоже, их игнорирует и ищет в своей базе. Если у него своя база не обновлена или вы используете сторонний плагин, то получаете No description available.
Если что, пока можно читать здесь.
Jenkins-плагин мы не поддерживаем. Возможно, стоит сообщить разработчикам. Вообще прикол в том, что если запускать findbugs в режиме xml:withMessages, то полные описания багов вываливаются прямо в результирующую xml-ку (в тегах BugPattern). Но Jenkins, похоже, их игнорирует и ищет в своей базе. Если у него своя база не обновлена или вы используете сторонний плагин, то получаете No description available.
Если что, пока можно читать здесь.
Закинул pull-request в Jenkins насчёт описаний багов.
Плагин к Jenkins обновили с моим pull-request'ом (версия 4.60).
Для начала — Спасибо за отличные статьи, как по FindBugs так и по Java! :)
Вопрос хоть и гуглится, но хотелось от Вас ответ услышать: А как Вы FindBugs в своих проектах применяете? Какой use case? Перед коммитом всё смотрите или при сборке на build сервере? Как решается проблема старых проектов — когда есть уже большой объём кода и если вводить анализатор кода, то он будет показывать кучу ошибок и будет трудно во всём этом разобраться при дальнейшей разработке проекта? В PVS Studio (анализатор для C++) есть возможность выводить только новые баги. (насколько я понял, сам то я им не пользуюсь).
Сам я когда то давно пробовал пользоваться статическими анализаторами кода, но как-то не пошло — тогда для меня было слишком накладно каждый раз запускать проверку по всему проекту. Сейчас пользуюсь IDEA и все её предупреждения по коду исправляю, благо она это говорит в run time при написании кода. А в FindBugs такое возможно?
Вопрос хоть и гуглится, но хотелось от Вас ответ услышать: А как Вы FindBugs в своих проектах применяете? Какой use case? Перед коммитом всё смотрите или при сборке на build сервере? Как решается проблема старых проектов — когда есть уже большой объём кода и если вводить анализатор кода, то он будет показывать кучу ошибок и будет трудно во всём этом разобраться при дальнейшей разработке проекта? В PVS Studio (анализатор для C++) есть возможность выводить только новые баги. (насколько я понял, сам то я им не пользуюсь).
Сам я когда то давно пробовал пользоваться статическими анализаторами кода, но как-то не пошло — тогда для меня было слишком накладно каждый раз запускать проверку по всему проекту. Сейчас пользуюсь IDEA и все её предупреждения по коду исправляю, благо она это говорит в run time при написании кода. А в FindBugs такое возможно?
Если у вас используется Hudson или Jenkins, поставьте плагин на сервер сборки. Запуск FindBugs придётся настраивать, но это несложно. Ему главное передать три вещи: пути к скомпилированным классам, пути к зависимостям (сторонние библиотеки, которые используются, но искать в них баги не надо) и пути к исходникам. Везде в качестве путей можно указать один или несколько каталогов или jar-файлов. В Hudson/Jenkins автоматически высвечиваются новые и исправленные с последнего билда сообщения:
Новые, конечно, стоит просматривать в первую очередь. Старыми можно заниматься постепенно, они каши не просят (у нас в проектах сейчас по 2000 старых сообщений бывает). В первую очередь смотреть сообщения с высоким rank в категории correctness. Потом style (dodgy code), потом bad practice. В последнюю очередь malicious code vulnerability и performance. Для начала можно отключить все сообщения с rank > 18: пропадёт примерно половина. Со временем стоит завести xml-файл с фильтрами и выключать сообщения, которые не нравятся.
IDEA не пользовался, но там вроде нормальный плагин есть. В Eclipse интеграция проходит легко, можно без дополнительной настройки запустить проверку. У меня проект на 7000 классов полностью проверяется минуты три. Полную проверку можно запустить где-нибудь перед уходом на обед. В Eclipse есть инкрементальная проверка (галочка в настройках, срабатывает при сохранении текущего файла), ей я пользуюсь при разработке самого FindBugs. Не знаю, как с этим в IDEA: там же сохранения нет. Может, можно на компиляцию повесить или на отдельную хоткею. Некоторые детекторы с инкрементальной проверкой не очень дружат, но большинство работает исправно.
Новые, конечно, стоит просматривать в первую очередь. Старыми можно заниматься постепенно, они каши не просят (у нас в проектах сейчас по 2000 старых сообщений бывает). В первую очередь смотреть сообщения с высоким rank в категории correctness. Потом style (dodgy code), потом bad practice. В последнюю очередь malicious code vulnerability и performance. Для начала можно отключить все сообщения с rank > 18: пропадёт примерно половина. Со временем стоит завести xml-файл с фильтрами и выключать сообщения, которые не нравятся.
IDEA не пользовался, но там вроде нормальный плагин есть. В Eclipse интеграция проходит легко, можно без дополнительной настройки запустить проверку. У меня проект на 7000 классов полностью проверяется минуты три. Полную проверку можно запустить где-нибудь перед уходом на обед. В Eclipse есть инкрементальная проверка (галочка в настройках, срабатывает при сохранении текущего файла), ей я пользуюсь при разработке самого FindBugs. Не знаю, как с этим в IDEA: там же сохранения нет. Может, можно на компиляцию повесить или на отдельную хоткею. Некоторые детекторы с инкрементальной проверкой не очень дружат, но большинство работает исправно.
Спасибо за развёрнутый ответ! Попробую на Jenkins поставить — было бы непохо динамику видеть по багам. Получается также как и по тестам — сколько всего, какие новые упали. :-)
В IDEA в плагине тоже есть инкрементальные проверки. Пока особо не смтрел, но в ближайшее время опробую.
В IDEA в плагине тоже есть инкрементальные проверки. Пока особо не смтрел, но в ближайшее время опробую.
В первую очередь смотреть сообщения с высоким rank в категории correctness. Потом style (dodgy code), потом bad practice. В последнюю очередь malicious code vulnerability и performance. Для начала можно отключить все сообщения с rank > 18: пропадёт примерно половина.
может выложите примерный такой минимальный конфиг для старта? (пока нет времени гуглить составлять такой)
Пробовал в Gradle настроить FindBugs 3.0.1 — не найден в maven репозиториях. Вот только 3.0.0 есть: mvnrepository.com/artifact/com.google.code.findbugs/findbugs
FindBugs отличный инструмент для поиска ошибок на уровне кода.
Я работаю Performance Analyst (высокооплачиваемый дворник вычищающий код) и часть работы это просмотр кода и исправление ошибок. Когда вы приходите к клиенту, вам говорят буквально «вот система сделай ее быстрее». Для того чтобы хоть немного оценить масштаб работы нужно просмотреть код. Понятно, что документации и тестов нет. И как раз в этой ситуации помогает статический анализатор. Если код более менее чистый, то сразу можно переходить на архитектуру (как работает, топология и тд).
Интеграция FindBugs с maven это скорее уже на окончание работы, чтобы не допускать ошибок в будущем.
Я работаю Performance Analyst (
Интеграция FindBugs с maven это скорее уже на окончание работы, чтобы не допускать ошибок в будущем.
Sonar'овцы обещают переделать все правила FindBugs в своём Java плагина анализа кода. В отличие от FindBugs и PMD он работает и на уровне исходников и на уровне скомпилированных файлов.
Спасибо за ссылки на код в Идее, мы поправим данный код
FindBugs это хорошо. Но предлагаю попробовать PVS-Studio для Java.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вышел FindBugs 3.0.1