Статический анализ PHP кода на примере Symfony2 (часть 2)

[nazarpc]

Во-первых релиз с указанными фичами доступен уже давненько, вышла даже более новая версия с исправлениями foreach и приоритетов внутри if.
А во-вторых, я был удивлен сколько всего нашли Sensio Labs Insignts и Scrutinizer, даже при том, что пользуюсь PhpStorm уже давно и упомянутым плагином тоже.

Так что рекомендую пересмотреть политику передачи кода третьей стороне, с вероятностью 95% (навскидку) у вас там нет ничего такого, что нельзя вообще выложить в виде Open Source, пусть даже с запретом коммерческого использования другими.

[kalessil]

Так и есть. Только инспекция reference mismatch ещё не релизилась (в истории коммитов плагина видно).

Sensio Labs Insignts и Scrutinizer — очень продвинутые инструменты, я пробовал на приватных проектах и упоминаю при случае. По открытию исходников — не я решаю, а позиция менеджмента — закрытое ПО.

Sensio Labs Insignts очень хорошо работает с симфони проектами, а Scrutinizer еще и по уязвимостям хорошо специализируется. Вместе с Php Inspections (EA Extended) — это просто без комментов =)

nazarpc: а можете ссылки в личку кинуть с результатами от Scrutinizer и Insignts — мне любопытно?

[KonstantinKuklin]

плагин к IDE это хорошо, но не знаете ли вы подобный функционал, идущий как сканер, анализатор и какая-нибудь вебморда, чтобы мониторить ошибки в коде без передачи кода кому-то? (сенсио лабс, скрутинизер не подходят)
знаю, что можно экспортировать отчеты из шторма, но все же. Аля Coverity для PHP

[kalessil]

Подобный, к сожалению, не встречался.

Посмотрите, может что-то из этого вам пригодится — я обычно отвечаю в полном объеме, но по ссылке есть детали как интегрировать с git.

Ну и PHP CS Fixer, конечно, стоит использовать.

[Corpsee]

PHPCI можете попробовать, вроде как раз то, что вы хотите.

[kix]

О, я вижу, вы продолжаете развивать плагин! Спасибо, очень полезное дело!

[kalessil]

Да, надо довести его до экспертного уровня — всё ещё есть пробелы. Хотя результат мне определённо нравится.

Пожалуйста =) Сейчас правда остро встал вопрос пиара, но надеюсь, что это не затронет частоту релизов.

[Rathil]

На счёт «мертвого кода» — достаточно спорный анализ. Далеко не всегда 100% можно определить прохождения по ветке… Я бы сказал, что мало когда можно определить это…

[kalessil]

Анализом прохождения по всем веткам плагин и не занимается.

В примере сначала нашлась локальная неиспользуемая переменная (массив, в который была только запись). Уже по факту выяснилось что это мёртвый код.

Инспекция условных выражений тоже выводит на мёртвый код (if (false), if (false &&)) — в нашем проекте было несколько таких мест, по-моему в swiftmail было что-то похожее. В Symfony2, конечно же таких мест не нашлось.

[tagir_valeev]

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

А если бы единственное использование массива выглядело как $currentIds[$ace->getId()] = $currentIds[$ace->getId()]+1, анализатор бы понял, что массив бесполезен?

[kalessil]

Если совсем просто, то любое чтение массива (передача в другую переменную, простейшие операции и передача в аргументы функции) отключит предупреждение.

Поэтому:

— Да
— Нет (но анализатор ругнулся бы, т.к. можно сделать ++$currentIds[$ace->getId()] — тут ему ума хватает)

[CentOS]

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

1) Скажите, пожалуйста, в чем практический смысл оптимизации
Problem synopsis:      Safely use single quotes instead
Плагин все время просит заменить двойные кавычки на одинарные, я же в своем проекте придерживаюсь единого стиля с кавычками, только двойные в длинных строковых выражениях.
Например $this->log(Logger::INFO, «Load and calculate template»);

2)  Problem synopsis:      Safely use '… === ...', '… !== ...' constructions instead
Пример кода, где высвечивается эта подсказка
if ($data['type'] == 'img') {
$this->template_load_mask[$name] = 1;
}

Почему здесь лучше использовать ===, а не ==

Спасибо.

[kalessil]

Отвечу в личных сообщениях.

[DjOnline]

Почему же, всем интересно.

[kalessil]

Хорошо:

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

===/!== — типо-зависимая операция сравнения, с ней '0' не равно 0, а вот ==/!= думает по-другому — такая же беда как и с empty.

[vladkens]

//  return '' === $relativePath ? './' : $relativePath - оптимальный вариант

Ещё лучше:

return empty($relativePath) ? './' : $relativePath;

[kalessil]

Не лучше, скорее даже наоборот (смена поведения и полная потеря контроля над типами):

И, собственно, примеры, как empty портит жизнь:

    empty(array()); // true
    empty("0");   // true
    empty(new \ArrayObject());  // false

[LionAlex]

Ну в некоторых случаях это как раз плюс, а не минус. Также, вы рекомендуете count вместо empty, но count сильно медленней. Понятно, что это экономия на спичках, но все же.

[kalessil]

Плагин в таких случаях пытается понять, что же имелось ввиду — использовать count/null сравнение и т.д. — реверсинжиниринг по сути.
Цель — чётко описать в коде, что и как этот код делает. С учётом доступных оптимизаций, count вооще не проблема.

Это один из аспектов именно этого плагина — избавиться от каши в коде.

[kalessil]

В личных сообщениях попросили продублировать рекомендацию ещё одного плагина: PHP Advanced AutoComplete.

Дублирую: подсказывает стандартные варианты параметров, например, для date, ini_get, header и т.д.