Статический анализ кода в PHP: регулярные выражения

[Placido]

В последнем случае вместо инвертирования жадности *? эффективнее использовать инвертированный символьный класс [^<]*. Тогда и модификатор s не потребуется:

$content = preg_replace('#<esi\:remove>[^<]*</esi\:remove>#', '', $content);

[kalessil]

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

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

[Placido]

Согласен.

[NorthDakota]

Пришёл на роботу, прочитал статью, поставил плагин.

И к сожалению, он мне не понравился, так как зачастую «ругается» на вполне адекватные вещи.
Например:

protected $testArray = [
    'testKey' => 'testValue',
]

Ругнулся на запятую, мол php до фени ваша запятая и она будет игнорироватся интерпретатором, уберите её.
Так я знаю что она будет игнорироватся, поэтому и оставил её там. Тем более логика класа подразумевает что, возможно, я или другой разработчик дополнит масив, и вот тогда дифф в гите будет красивым и читабельным. Благодаря вот той самой запятой.

P.S. Хотел найти в настройках плагина «отключение» некоторых фич. Не нашёл…

[Reposlav]

Перемещаете курсор на запятую, нажимаете alt+enter или появившуюся лампочку, выбираете «Inspection options->edit inspection profile setting», убираете ненужную галочку. По крайней мере так в PhpStorm 7

[NorthDakota]

В 8 сработало. Спасибо!

[kalessil]

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

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

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

[kalessil]

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

[t1gor]

Спасибо, поставил. Будем пробовать.

А подскажите еще, пожалуйста, где найти настройки плагина?

[kalessil]

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

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

[t1gor]

Settings -> Editor -> Inspections -> PHP -> Php Inspections (EA Extended)

Спасибо, именно то, что искал.

[gro]

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

[kalessil]

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

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

[gro]

Да, но команда должна знать о таком нюансе, что \d это не только 0-9

[kirilloid]

0 === strpos($method, "get")

и

preg_match('/^get/', $method)

вообще-то не эквиваленты. regex будет работать быстрей на больших строках.
Хотя и эту оптимизацию можно провести через substr.

[kalessil]

Официальная документация говорит в пользу моего варианта:

Do not use preg_match() if you only want to check if one string is contained in another string. Use strpos() or strstr() instead as they will be faster.

[kirilloid]

Вы понимаете разницу между /get/ и /^get/?

[kalessil]

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

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

[kalessil]

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

[kirilloid]

Вот про эти случаи я и говорил. Извините, я хотел обратить внимание на тонкости того, что регулярка привязана к концу строки.
Кстати, я как-то видел, что регулярка с ^ работала быстро, а с $ — медленно (обе на больших строках). Правда, это было в каком-то javascript-движке (вроде, V8, но давно), но тем не менее такое возможно и в php, так что конечно проверять надо.

[kalessil]

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

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