В общем-то да.

Я по вот этим пунктам сужу:

• Elvis operator can be used
• Ternary operator simplification
• Not optimal if conditions

Остальное (кроме Control flow) — совсем базовые проверки.

На самом деле спасибо за комментарий, я как-то не за то зацепился =)

Думаю, что надо добавить ремарку про этот нюанс в текст анализатора.

ovr/phpsa: список правил слишком уж напоминает Php Inspections (EA Extended).

Про большие строки (например блоки XML), там же говорится что preg_match будет быстрее, про эти случаи вы правы.

Да, я прекрасно понимаю разницу и вам следует таки опираться на факты и публичные матералы, а не переходить на личности.

Вот ещё один пруф, что strpos будет бытрее.

А то, как и использовать === вместо ==.

На проверенных проектах надо вычищать либо в одну сторону, либо в другую: \d и [0-9] сосуществуют.

Но [0-9] гораздо реже используется, поэтому, выбор — решение команды, зависящие от конкретного проекта.

Пожалуйста. Настроить можно здесь: Settings -> Editor -> Inspections -> PHP -> Php Inspections (EA Extended)

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

В Probable Bugs что-нибудь интересное нашли?

Второе — это настроить под себя Code Style инспекции, чтобы сфокусироваться на других сообщениях.

Это как раз о таких вещах: запятые, двойные кавычки, вложенные условия.

Как вариант, Settings -> Editor -> Inspections -> PHP -> Php Inspections (EA Extended): просмотрите всё, что Code Style и настройте под ваши реалии.

Этот вариант меняет поведение, по спецификации возможны вложенные теги (во всяком случае мой пулл-реквест с этими правками завернули):

<esi:include src="http://www.example.com/ad.html"/> 
<esi:remove> 
  <a href="http://www.example.com">www.example.com</a>
</esi:remove>

Это немного разные вещи, сонар больше вещей может (полезных):

• работать с проектами на смеси языков — и считать метрики по ним всем
• предоставлять метрики
• рапортовать технический долг (ой как врёт, зараза)

Php Inspections (EA Extended) для старта можно дополнить Php Metrics — когда этого мало, уже пробовать сонар.

Классика жанра — ставим сонар, не знаем что делать с его отчётами, сносим.

Php Metrics ставится как плагин, сносить будет не жалко.

Ну пожалуйста, расскажите уже подробнее…

А можно кратко и сравнительно охарактеризовать различия?

PS: большое спасибо за ваши статьи, благодаря им повился вот этот анализатор для PHP.

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

Про проблему понял. Никак, к сожалению, приходится искать альтернативы.

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

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

Можно и SaaS (SensioLabs Insight, например).

Но корпоративный сегмент (который хорошо платит) не любит одавать код третьей стороне, поэтому вариант с SaaS для статического анализа просто не взлетит.

Если не лезть в дебри кода, то обратная совместимость минорных релизов — на моей памяти только они это обещание сдержали.

Часть абстракции именно для того, чтобы сложно было напортачить (высокий порог вхождения).

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

Например,

FindBugs (Java) уже умеет находить проблемы с многопоточностью.
Этот анализатор (PHP) умеет находить проблемы с шаблонами проектирования и памятью.
Можно вспомнить ещё ReSharper Inspections.

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