Static code analysis 2

Это вторая часть цикла. Начало: http://itech-notes.blogspot.com/2014/09/sca-1.html 

КАКИЕ СРЕДСТВА АНАЛИЗА МОЖНО ИСПОЛЬЗОВАТЬ?

Я уже писал, что SCA - это анализ с помощью специальных инструментов? В любом случае, это так. Какие же инструменты существуют?

Что такое компилятор/транслятор? Это штука, которая преобразует исходный код в объектные файлы (С) либо в байт-код (java). Для этого она выполняет лексический анализ (разбирает, что написано, какие лексемы), синтаксический анализ (какие обобщённые конструкции применяются) и статический анализ (ошибки этапа компиляции).

Т. о., может показаться забавным, но одними из самых эффективных анализаторов кода являются сами компиляторы. Конечно, предназначены они совсем для другого, но в качестве бонуса каждый из них предлагает неплохой верификатор исходников, способный обнаружить большое количество ошибок. Почему же он не спасает? Изначально настройки такой верификации кода выставлены достаточно лояльно: в результате, чтобы не смущать программиста, компилятор начинает ругаться только в случае самых серьёзных косяков. А вот и зря – если поставить уровень предупреждений повыше, вполне реально откопать немало сомнительных мест в коде.

Поэтому простейший инструмент SCA, который «всегда с собой» – это компилятор.

IntelliJ IDEA

IDE IntelliJ IDEA имеет свой SCA. Этот SCA работает в 2-х видах

Idea позволяет выявить десятки типов ошибок и противоречий. Прежде всего, она помогает найти возможные «баги», которые не являются ошибками компиляции. Её гибкий механизм решения проблем позволяет легко улучшить структуру кода, упростить следование многочисленным стандартам, выявить проблемы производительности и т. д.
Такой SCA выполняется "на лету" - различные противоречия, возможные баги, избыточность и т. д. подсвечиваются сразу во время написания программного кода. Более того, также предлагается intelligent quick-fixes.

Более полный анализ вызывается из меню Analyze –> Inspect Code.... Перечень проводимых инспекций также настраивается.
В общем-то, по умолчанию инспекций не много – ориентировочно, около сотни. Но вот если установить плагин Inspection Gadgets... – более 600 (632) инспекций кода, сгруппированных по целям и назначению. Каждая инспекция имеет описание. Основные задачи этих инспекций:

• Finding probable bugs
• Locating the "dead" code
• Detecting performance issues
• Improving code structure and maintainability
• Conforming to coding guidelines and standards
• Conforming to specifications

http://www.jetbrains.com/idea/documentation/inspections.jsp – IDEA Inspections List
http://www.jetbrains.com/idea/documentation/static_code_analysis.html – Static Code Analysis
http://itech-notes.blogspot.com/2012/07/noinspection-intellij-idea.html - //noinspection в IntelliJ IDEA

• Class structure: структура класса – final, static, public/protected/private, внутренние классы, конструкторы и пр.
• Code style issues: особенности стиля кодирования – избыточность, необязательные модификаторы и пр.
• Control flow issues: анализ потока выполнения (циклы, условия, ветви) – break/continue, if/else (постоянные условия, дубликаты), switch/for/if, отсутствие или избыточность и пр.
• Declaration redundancy: избыточность объявления переменных, исключений, пустые методы, неиспользуемые параметры и пр.
• Error handling: обработка исключений (в java мощный механизм исключений, но часто его используют как попало; вместе с тем это одна из основных и классических проблем, приводящих к проблемам кода) – проброс исключений без обработки, неверное применение finally (continue, return, throw), неправомерный перехват исключений (NPE, IllegalMonitorStateEx, ArrayIndexOutOfBoundsEx), неправомерное объявление исключений для метода и throws (java.lang.Exeption/Throwable/Error/ RuntimeEx/NPE/ClassCastEx/ ArrayIndexOutOfBoundsEx).
• JUnit issues: различные проблемы при использовании JUnit – setUp/tearDown, ассерты.
• Memory issues: явный вызов System.gc()/Runtime.gc(), статические коллекции, создание массивов нулевой длины.
• Naming conventions: выполнение требований по именованию классов/полей/методов.
• Performance issues: отслеживает код, для которого существуют более быстрые и производительные паттерны (например, StringBuilder вместо прямой конкатенации строк).
• Resource management issues: работа с ресурсами – открытие каналов/I-O/JDBC/JNDI/Socket без безопасного закрытия.
• Security issues: доступ к системным свойствам, небезопасное применение SecurityManager и ClassLoader.
• Threading issues: работа с потоками – работа с wait/notify/start/stop; синхронизация (на статических объектах, this).
• Probable bugs: бесконечные циклы, отсутствие проверок методов на возвращённый результат, возврат null в методе, ошибки equal/equals, compareto/compareTo, tostring/toString, индекс 0 в JDBC RS.

Дополнительно можно настраивать свои шаблоны с помощью «структурального поиска и замены».