Программа для проверки java кода

Обновлено: 02.07.2024

Чистота и качество кода — важные критерии оценки работы программиста. Если код работает — это уже хорошо, но нельзя забывать о том, что он должен быть очищен от «мусора», быть логичным и понятным для других разработчиков.

Выполняет статический анализ кода C / C ++ с использованием инструментов с открытым исходным кодом, таких как cppcheck и clang-tidy, и автоматически создает документацию по коду для пользователей, использующих doxygen. Этот инструмент можно использовать бесплатно.

Полный рабочий процесс для написания, проверки и развертывания кода, бесплатная учетная запись для 1 пользователя и 1 репозитория со 100 МБ хранилища.

Кроссбраузерное онлайн-тестирование. Предоставляет в ваше распоряжение любой IE от 5.5 до 9, а также последние версии Explorer, Opera, Chrome, Safari и Firefox.

Автоматическая проверка кода для PHP, Python, Ruby, Java, JavaScript, Scala, CSS и CoffeeScript, бесплатно для неограниченного количества общедоступных и частных репозиториев.

Автоматизированная инфраструктура как инструмент проверки кода для DevOps, интегрируется с GitHub, Bitbucket и GitLab (даже самостоятельно). Помимо стандартных языков, он анализирует также Ansible, Terraform, CloudFormation, Kubernetes и другие. Бесплатно с открытым исходным кодом.

Автоматическая проверка кода, бесплатная для Open Source и неограниченное количество частных репозиториев, принадлежащих организации (до 4 соавторов). Также бесплатно для студентов и учреждений.

Инструмент покрытия кода (SaaS), бесплатно с открытым исходным кодом и 1 частного репозитория.

Автоматическая проверка кода для Git. Бесплатная версия включает неограниченное количество пользователей, неограниченное количество публичных репозиториев и 1 частный репозиторий.

Отдает приоритет техническому долгу в зависимости от того, как разработчики работают с кодом, и визуализирует такие организационные факторы, как объединение команд и системное мастерство. Бесплатно с открытым исходным кодом.

Показывает какие части вашего кода не охватываются вашим набором тестов. Бесплатно для репозиториев с открытым исходным кодом. Версия Pro для частных репозиториев.

5 бесплатных отчетов по анализу веб-производительности, доступности и безопасности каждый месяц.

Находит ошибки уязвимости, безопасности, проблемы с производительностью и API на основе ИИ. Скорость анализа DeepCode позволяет анализировать ваш код в режиме реального времени и предоставлять результаты, когда вы нажимаете кнопку сохранения в своей среде IDE. Поддерживаемые языки: Java, C / C ++, JavaScript, Python и TypeScript. Бесплатно для открытых исходных кодов и частных репозиториев, бесплатно до 30 разработчиков.

Расширенный статический анализ для автоматического поиска ошибок времени выполнения в коде JavaScript, бесплатно для Open Source.

Анализирует изменения исходного кода, находит и исправляет проблемы, классифицируемые по следующим категориям: безопасность, производительность, анти-шаблоны, риски ошибок, документация и стиль.

Платформа № 1 для оптимизации баз данных. Получайте критически важную информацию о своей базе данных и SQL-запросах с помощью автоматической магии.

Оценка покрытия кода тестами для всех пакетов Go.

Отчеты и подробные рекомендации по оптимизации веб-сайтов.

Статический анализатор кода для оптимизации PostgreSQL. Служба автоматического обнаружения проблем с производительностью, безопасностью и архитектурой базы данных.

Комментирует проблемы качества и стиля кода, что позволяет вам и вашей команде лучше проверять и поддерживать чистую кодовую базу.

Дружелюбный робот, который оптимизирует ваши изображения и экономит ваше время. Оптимизированные изображения означают меньшие размеры файлов без ущерба для качества.

Бесплатный API, обеспечивающий оптимизацию изображений.

Обзор кода для репозиториев GitHub, бесплатно для публичных или личных репозиториев.

Лучший набор инструментов: от непрерывной интеграции и непрерывного анализа до расширения возможностей анализа человеческого кода с помощью интеллектуального кода.

Помогает командам инженеров максимизировать продуктивность, автоматически анализируя каждый запрос в соответствии с индивидуальными наборами правил для каждого проекта, а также с общими передовыми практиками.

Предоставляет метрики и аналитические данные на основе данных, собранных с GitHub и GitLab. Обеспечивает видимость на каждом этапе конвейера доставки в решении для данных и аналитики для инженерных команд.

Анализирует изменения, внесенные в каждый запрос на вытягивание, и улучшает опыт разработчиков при проверке кода. Бесплатно для открытого исходного кода и бесплатно для личного использования.

Спасибо за прочтение. Надеемся будет полезно. Если мы забыли упомянуть что-то важное или новое — пишите в комментарии.

Подписывайтесь на наш канал в Telegram, там вы найдете более 800 полезных сервисов на все случаи жизни.

Встроенный анализатор IntelliJ IDEA

SonarJava

    правил обнаружения ошибок; правил распознавания запахов кода; правил обнаружения потенциальных уязвимостей;
  • Интеграция с Maven, Gradle, Ant, Eclipse, IntelliJ IDEA, VS Code;
  • Возможность расширения с помощью настраиваемых диагностических правил;
  • Специализированный инструмент SAST: большинство диагностических правил составлено в соответствии с CWE, CERT, OWASP.

FindBugs / SpotBugs

    правил обнаружения ошибок;
  • Интеграция в Ant, Maven, Gradle, Eclipse, IntelliJ IDEA;
  • Возможность расширения с помощью настраиваемых диагностических правил.

PVS-Studio

  • Анализ потока данных;
  • Символическое исполнение;
  • Аннотации методов;
  • Анализ на основе шаблонов.
  • Анализатор ориентирован на поиск реальных ошибок;
  • Помимо версии CLI, есть также интеграция с IntelliJ IDEA, Maven, Gradle, Jenkins, SonarQube;
  • Возможность запуска анализатора в инкрементальном режиме;
  • Анализатор выявляет потенциальные проблемы совместимости с Java SE API при переносе проекта с Java 8 на более свежие версии;
  • PVS-Studio конвертирует отчет в различные удобные для пользователя форматы: JSON, XML, HTML, TXT;
  • Специализированный инструмент SAST: большинство диагностических правил составлено в соответствии с CWE, CERT, OWASP.
    с различными IDE (IntelliJ IDEA, Eclipse, NetBeans) и системами сборки (Maven, Gradle, Ant);
  • Поддерживает различные форматы отчетов анализатора: SARIF, CSV, IDEA, JSON, текст (по умолчанию), XML, HTML, TextColor и так далее;
  • Имеет более 300 шаблонов диагностических правил. Категории: стиль кодирования, лучшие практики, ошибки, многопоточность, производительность и так далее;
  • Поставляет CPD (детектор копирования-вставки) вместе с PMD, который обнаруживает дубликаты в коде.

Заключение

  • интеграция в различные IDE;
  • интеграция в системы сборки;
  • удобство запуска анализатора на сервере;
  • возможность обнаружения ошибок в режиме редактирования кода;
  • возможность удобной работы с предупреждениями;
  • ориентация на SAST;
  • процент ложных срабатываний;
  • сложность конфигурации.
  • Сочетание всех плюсов и минусов приведет вас к количеству статических анализаторов, которые вы сочтете лучшими.

Ошибки в куче и стековой памяти Java

  • Куча памяти — это специальная область памяти, в которой хранятся java-объекты.
  • Стековая память — область временной памяти для хранения переменных при вызове метода.

Java Heap Space

Эта ошибка возникает, когда программе Java не удалось выделить новый объект в области памяти кучи.

GC Overhead Limit Exceeded

Программа Java тратит слишком много времени на сборку мусора. Такая ошибка появляется тогда, когда сборка мусора занимает 98% времени программы и восстанавливает менее 2% пространства памяти. Здесь stringList содержит ссылку на наши сгенерированные строки, поэтому сборщик мусора не может удалить сгенерированные строки из памяти, а пытается удалить любой другой мусор в приложении. Но этого недостаточно.

Запрошенный размер массива превышает предел виртуальной машины (Requested Array Size Exceeds VM Limit)

Ошибка возникает при попытке выделить массив, когда места в куче недостаточно.

Метапространство (Metaspace)

Нет места для подкачки (Request Size Bytes for Reason. Out of Swap Space?)

Ошибка появляется, когда не удалось выделить память в собственной куче или ее размер недостаточен.

reason stack_trace_with_native_method

Собственный интерфейс Java или собственный метод не смогли выделить память в куче. StackOverFlowError — когда слишком много вызовов методов. Обычно исключение вызывается методом, внутри которого есть рекурсия.

Чистота и качество кода - важные критерии оценки работы программиста. Если код работает — это уже хорошо, но нельзя забывать о том, что он должен быть очищен от «мусора», быть логичным и понятным для других разработчиков. Ведь нередко работа одного программиста — это лишь часть кода крупной программной платформы, которую придется обслуживать в будущем. Скорее всего, другим людям.

В компаниях ревью кода обычно проводят сеньоры. Но их время — дорогое. Если хотя бы частично избавить сеньора от этой нагрузки, он может стать гораздо эффективней для компании. Чтобы при этом сохранять качество кода на высоком уровне, стоит использовать онлайн-сервисы оценки готового кода. Эта статья поможет вам выбрать один или несколько таких инструментов.


Reshift

  • Интеграция с Github и Bitbucket.
  • Пул-реквесты без переключения на другие дашборды во избежание путаницы.
  • Умная маркировка проблемных мест.
  • Отслеживание уязвимостей в каждой ветке.
  • Показ критических уязвимостей перед мерджем с главной веткой.


Collaborator

Один из наиболее продвинутых инструментов ревью кода. Подойдёт как для работы команд, так и для отдельных разработчиков.

  • Контроль за изменениями кода, определение проблем, создание комментариев.
  • Создание правил и уведомлений на их основе.
  • Кастомные поля, чеклисты, группы участников.
  • Интеграция с 11 разными SCM и IDE, в том числе Eclipse и Visual Studio.
  • Персонализированные ревью-отчеты.


Gerrit

Бесплатный онлайн-сервис проверки качества кода, который позволяет работать прямо в браузере, отклоняя или одобряя изменения. Сочетает в одной платформе багтрекер и инструмент ревью кода.

  • Интеграция с Git — возможность управления репозиториями Git через Gerrit.
  • Настраиваемая иерархия кода.
  • Добавление комментариев при внесении изменений.
  • Система голосований по вносимым изменениям


Codestriker

Ещё один неплохой open-source инструмент для ревью кода. Онлайн-сервис Codestriker позволяет быстро найти проблемы в коде и улучшить общее его качество.

  • Фиксирование всех проблем, решений и комментариев в базе данных. Впоследствии к ней можно вернуться и посмотреть, что было сделано, какие изменения внесены.
  • Интеграция с ClearCase, Bugzilla, CVS и не только


Crucible

Онлайн-приложение для ревью кода, поиска проблем, обсуждения изменений в отдельных ветках, шеринга данных и т.п. Crucible не бесплатный сервис. Есть две версии — для небольших команд и для корпораций. В первом случае нужно один раз заплатить $10, после чего становятся доступными безлимитные репозитории для 5 пользователей. Корпоративная версия стоит $1100, покупатель получает возможность открыть безлимитный репозиторий для 10 пользователей. Есть демо-доступ на 30 дней.

  • Совместная работа как 2-3 программистов, так и больших групп разработчиков.
  • Возможность ревью кода как до, так и после внесения изменений.
  • Совместимость с SVN, Perforce и CVS.


Review Board

Ещё один бесплатный open-source инструмент, который применяется для ревью кода и отдельных документов. Можно попробовать демо-версию на сайте разработчика или же установить инструмент его на своём сервере. Хорош он тем, что даёт возможность лоб в лоб сравнить две версии кода — с изменениями и без — через простой интерфейс.

Существует сервис уже около десяти лет, и всё это время его создатели продолжают совершенствовать Review Board, добавляя новые функции и улучшая существующие.

  • Простая интеграция в ClearCase, CVS, Perforce, Plastic.
  • Выделение участков кода с проблемами или заданными параметрами.
  • Возможность использовать инструмент для ревью кода как до, так и после внесения изменений.


GitHub

Наверное, нет разработчика, который бы не слышал о GitHub, но как автоматический ревьюер кода он известен гораздо меньше. Здесь у него есть две версии — бесплатная, с ограничением по количеству пользователей, и платная, от $7 в месяц.

В дополнение к обычным инструментам запроса на изменения, есть возможность проверят историю изменений, комментировать участки кода, разрешать простые конфликты при помощи веб-интерфейса. Кроме того, GitHub даёт возможность использовать и сторонние инструменты ревью кода.

  • Сравнение фрагментов кода лоб в лоб.
  • Просмотр истории отдельных фрагментов кода без просмотра всего документа — так называемый blame view.
  • Создание white-листов по отдельным веткам.


Phabricator

Это целый набор open-source инструментов от Phacility, облегчающих работу по оценке кода. Можно использовать облачную версию, а можно загрузить всё на свой сервер. Если использовать второй вариант — ограничений нет. В случае же облачной версии нужно будет платить от $20 за пользователя в месяц. Верхняя планка - $1000 в месяц. Все платные предложения включают техническую поддержку, плюс 30-дневный пробный режим.


Rhodecode

Онлайн-инструмент, который поддерживает три версии систем контроля: Mercurial, Git и Subversion. Сервис не бесплатен. Цены начинаются с $8 в месяц за пользователя. Есть возможность заплатить сразу $75 за пользователя в год, что позволяет сэкономить пару десятков долларов. Если не хочется платить, можно загрузить community-edition, установив на своём сервере.

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

Завершая подборку, повторим: описанные инструменты для ревью кода не призваны полностью заменить человека. Но они позволяют ускорить проверку во много раз, что даёт возможность значительно экономить время и ресурсы.

А какими инструментами пользуетесь вы? Ждём комментариев, поделитесь с коллегами :)

Код, который пишет программист, должен быть рабочим – самое первое правило успешной работы, с которым согласится и сам программист, и все его начальники. Но, кроме того, что код должен просто работать, часто к нему предъявляются повышенные требования – наличие комментариев (внутренней документации), читаемость, быстроту внесения изменений, совместимость с явными и неявными стандартами. Всё то, что можно назвать качеством кода.

  • Компилирование всего кода
  • Работоспособность всего кода
  • Соответствие стилю написания кода, используемого в проекте
  • Наличие документации для каждого участка кода
  • Удобочитаемость кода на уровне отдельных строк, функций, файлов
  • Возможность быстрого внесения изменений в код, затрагивая минимальный существующий функционал

Компиляция

К сожалению, ещё встречаются в нашей жизни ситуации, когда код на проекте не компилируется целиком. В дереве кода встречаются участки, написанные несколько лет назад, которые никто не трогал, никто не менял, и они сами собой как-то перестали не только работать, но и даже компилироваться. При этом эти участки кода не используются в 99%, 99,9% или даже в 99,98% случаев, но когда настанет час X (а по закону Мэрфи он обязательно настанет именно в production-системе), заказчик будет очень огорчён.

Можно ли с этим бороться? Нужно! Вручную – полной периодической компиляцией всего кода в проекте, а лучше автоматически. Например, настроить еженочную компиляцию кода, а лучше заодно и выкладывание этого кода на так называемый «интеграционный сервер» — на котором будет самый свежий, возможно, местами неработающий код. Но зато на этом сервере вы всегда будете иметь актуальное состояние вашего проекта, и уж точно не пропустите ошибок компиляции.

Отдельной строкой стоит упомянуть компиляцию не-java файлов. Почти для любых скриптов, и для JSP-страниц, существует способ проверить файл на наличие ошибок компиляции. Например, в WebLogic вы можете указать параметр precompile для вашего веб-приложения. Если какая-нибудь JSP будет содержать ошибки, прекомпиляция прервётся и выведет ошибку в лог. Также существует утилита jspc, входящая в состав WebLogic, выполняющая ту же функцию для отдельных jsp.

Работоспособность

Ваш код работает? А откуда вы знаете? Можете ли вы сказать, весь ли код работает прямо сейчас, или же какая-то часть точно работала недели две назад, а сейчас может уже и не работает? Но ведь вы сами знаете, что практически любое изменение может «сломать» что-то не там, где надо, и даже там, где не надо.

Или же ваша уверенность основывается на том, что отдел QA (quality assurance) поставил «passed» на все ваши bugs/issues/patches? Так это ещё ничего не значит! Во-первых, в некоторых компаниях QA тестирует только изменившиеся части системы. Во-вторых, QA бывает ленивым и непрофессиональным, и, как показывает мой недавний опыт в некоторой неназываемой компании, может просто поставить passed на тест, который просто лень было проходить. В-третьих, скорее всего в QA тоже работают люди, и они тоже могут допускать ошибки.

  • автоматические тесты были
  • эти автоматические тесты должны покрывать 100% функционала

Если первый пункт является организационной задачей, то второй — технической. И под «100%» нужно понимать не наличие теста на каждое требование в неких requirements'ах, а то, что каждая строчка кода будет исполнена в результате исполнения хотя бы одного теста. Данная характеристика называется «code coverage» и буквально означает степень покрытия кода тестами. Различаются следующие показатели:

  • Function Coverage — подсчёт по вызовам методов
  • Decision Coverage – подсчёт по возможным направлениям исполнения кода (then-else или case-case-default в управляющих структурах). Учитывает единственное ветвление в каждом конкретном случае.
  • Statement Coverage – подсчёт по конкретным строчкам кода
  • Path Coverage – подсчёт по возможным путям исполнения кода. Более широкое понятие, чем decision coverage, так как учитывает результат всех ветвлений.
  • Conditional Coverage – подсчёт по возможным результатам вычисления значениям булевских выражений и подвыражений в коде.

EclEmma — Java Code Coverage for Eclipse


EclEmma — Java Code Coverage for Eclipse

Стиль

Код должен удобно читаться, а не удобно писаться
Стив МакКоннелл (Steve McConnell), SD West '04
(автор статьи не совсем согласен с данным высказыванием,
но приводит его как авторитетное мнение авторитета)

Хорошо, предположим ваш код работает. Ещё от него хочется, чтобы он был понятным. Для этого используется много техник и правил, и самое первое — соответствие оформление кода некоторому стилю. Например, у нас в компании используется следующий стиль: «Sun Java Conventions + <> on new line». Хочется выразить благодарность авторам столь понятной концепции. Потому что в моём IDE мне достаточно взять правила оформления «Java Conventions», скопировать в новые, и поменять всего одну (ну ладно, пять если честно), настройку.

Частично статистический анализ может выполнить и IDE (Eclipse — при компиляции, IDEA — «Code Inspections»). Утилиты разделяют на две группы — на те, которые работают с исходным кодом (большинство), и на те, которые работают уже со скомпилированными файлами. Стоит отметить, что FindBugs работает с компилированным кодом, то есть проверку может провести и ваш начальник, и ваш заказчик… думаю, лучше позаботится, чтобы там был хороший результат (смайлик).

Документация

Уж сколько слов сказано о необходимости документации к коду… Остановлюсь лишь на том, что современные IDE позволяют автоматически подчёркивать те места кода, где отсутствует javadoc-комментарий, проверять правильность его оформления, наличие всех необходимых тегов ( @since , @param , @author , etc). Ищите в настройках и обязательно включите это хотя бы для public-методов и классов (а лучше и для protected).

Также есть и специальные программы, которые позволяют проанализировать код на присутствие JavaDoc-комментариев. Например, уже упоминавшийся CheckStyle.
Конечно, это не заменит пару страниц документации от разработчика простым текстом с парой рисунков, на которых бы он объяснил, где в коде точка входа, выхода, и нарисовал хотя бы примерный путь между ними.

Удобочитаемость кода

  • размер отдельной строки не более 120 символов, чтобы помещалась на экране
  • размер метода не более одного экрана, чтобы читатель мог охватить весь метод взором и понять, что он делает
  • размер класса не более 1000 строк — отсутствие BLOB-антипаттерна
  • отсутствие «магических» констант (например, 5, 7, 10… читатель должен легко понять, что это за цифры и откуда они берутся)

Подводя «итоги»

  • Если у вас нет системы контроля версий, то стоит её завести. Хотя, надеюсь, она у вас всё-таки есть, иначе к чему вся эта статья?
  • Если в компании существуют определённые правила (шаблоны) написания кода, ограничения, то их стоит формализовать, и, по возможности, описать на языке, понятным одной из автоматических утилит.
  • Настроить выделенный сервер (интеграционный), который каждую ночь будет брать из текущего HEAD/Stream весь код, компилировать его и «выкладывать» на сервер. Сервер, желательно, должен быть запущен в режиме -ea (enable assertions), хотя бы на тот код, который вы писали.
  • В процессе компиляции код надо проверить утилитами, работающими с исходным кодом (например, Checkstyle), а после — утилитами, работающими с байт-кодом (например, FindBugs)
  • Результат компиляции, особенно если есть ошибки, послать на почту
  • После перезагрузки сервера — провести на нём серию автоматических тестов.
  • При исполнении тестов было бы неплохо подключить утилиты для оценки coverage, а также какую-нибудь внутреннюю статистику производительности. Результаты можно сохранять в базе данных, и через некоторое время накопить хорошие показатели того, как вы улучшаете, ускоряете или замедляете код в процессе разработки.

Придя с утра, программист должен получить от сервера задач — список задач на день, а от интеграционного — текущее положение дел с кодом.

Читайте также: