Плагин в таких случаях пытается понять, что же имелось ввиду — использовать count/null сравнение и т.д. — реверсинжиниринг по сути.
Цель — чётко описать в коде, что и как этот код делает. С учётом доступных оптимизаций, count вооще не проблема.
Это один из аспектов именно этого плагина — избавиться от каши в коде.
Двойные кавычки в плагине — стиль кода. В предыдущей статье обсудили что с оп-кешем двойные или одинарные кавычки — на производительность никак не повлияет. Отключите, если вы используете двойные.
===/!== — типо-зависимая операция сравнения, с ней '0' не равно 0, а вот ==/!= думает по-другому — такая же беда как и с empty.
Если совсем просто, то любое чтение массива (передача в другую переменную, простейшие операции и передача в аргументы функции) отключит предупреждение.
Поэтому:
— Да
— Нет (но анализатор ругнулся бы, т.к. можно сделать ++$currentIds[$ace->getId()] — тут ему ума хватает)
Анализом прохождения по всем веткам плагин и не занимается.
В примере сначала нашлась локальная неиспользуемая переменная (массив, в который была только запись). Уже по факту выяснилось что это мёртвый код.
Инспекция условных выражений тоже выводит на мёртвый код (if (false), if (false &&)) — в нашем проекте было несколько таких мест, по-моему в swiftmail было что-то похожее. В Symfony2, конечно же таких мест не нашлось.
Так и есть. Только инспекция reference mismatch ещё не релизилась (в истории коммитов плагина видно).
Sensio Labs Insignts и Scrutinizer — очень продвинутые инструменты, я пробовал на приватных проектах и упоминаю при случае. По открытию исходников — не я решаю, а позиция менеджмента — закрытое ПО.
Sensio Labs Insignts очень хорошо работает с симфони проектами, а Scrutinizer еще и по уязвимостям хорошо специализируется. Вместе с Php Inspections (EA Extended) — это просто без комментов =)
nazarpc: а можете ссылки в личку кинуть с результатами от Scrutinizer и Insignts — мне любопытно?
Судя по голосованию, интерес есть, поэтому создавайте проект на github, добавляйте ссылку в статью.
Сможете продуктивно работать с единомышленниками и собирать фидбек в виде issues/pull requests.
Ну а там видно будет взлетел проект и стагнировал — в любом случае вы в плюсе. Удачи!
Проекты разные бывают, и они живут и развиваются в опредленной инфраструктуре. Большие проекты и инфраструктуру не переписать и не выбросить — это огромные деньги и риски для бизнеса.
Я подозреваю, что для ФБ дешевле допилить Hack, чтобы:
— сохранить команду;
— сохранить работающие решения;
— уменьшить стоимость разработки и сопровождения;
Поэтому будут самые разнообразные проекты PHP/JVM, .NET/JVM, LLVM =)
1. а зачем JVM байт код? у HHVM свой байт-код и свой JIT
2.… сейчас ничего не мешает выполнять PHP в JVM
1) HHVM — поддерживает и PHP (слабая типизация) и Hack (стогая типизация). Поэтому всё своё (JVM — строгая типизация, поэтому нет полной совместимости).
2) JPHP — «We don’t plan to implement the zend runtime libraries», не для больших продакшн проектов. Да и HHVM выглядит привлекательнее, плюс мощные оптимизации c++ компиляторов.
Hack слишком узко применим, по сути кроме как в facebook врятли где еще стоит его использовать + даже внутри facebook я думаю задача взять и переписать все на hack не стоит
Тут я своего мнения ещё не сформировал окончательно. Но я надеюсь, что примитивные и возращаемые типы перекочуют в PHP как можно быстрее.
И цикл жизни/сопровождения такого приложения заканчивается переписыванием оного с нуля.
Если можно, то с привязкой в области (интерпрайз, е-коммёрс, мультимедиа и сми).
Цель — чётко описать в коде, что и как этот код делает. С учётом доступных оптимизаций, count вооще не проблема.
Это один из аспектов именно этого плагина — избавиться от каши в коде.
Двойные кавычки в плагине — стиль кода. В предыдущей статье обсудили что с оп-кешем двойные или одинарные кавычки — на производительность никак не повлияет. Отключите, если вы используете двойные.
===/!== — типо-зависимая операция сравнения, с ней '0' не равно 0, а вот ==/!= думает по-другому — такая же беда как и с empty.
Дублирую: подсказывает стандартные варианты параметров, например, для date, ini_get, header и т.д.
И, собственно, примеры, как empty портит жизнь:
Поэтому:
— Да
— Нет (но анализатор ругнулся бы, т.к. можно сделать ++$currentIds[$ace->getId()] — тут ему ума хватает)
В примере сначала нашлась локальная неиспользуемая переменная (массив, в который была только запись). Уже по факту выяснилось что это мёртвый код.
Инспекция условных выражений тоже выводит на мёртвый код (if (false), if (false &&)) — в нашем проекте было несколько таких мест, по-моему в swiftmail было что-то похожее. В Symfony2, конечно же таких мест не нашлось.
Пожалуйста =) Сейчас правда остро встал вопрос пиара, но надеюсь, что это не затронет частоту релизов.
Посмотрите, может что-то из этого вам пригодится — я обычно отвечаю в полном объеме, но по ссылке есть детали как интегрировать с git.
Ну и PHP CS Fixer, конечно, стоит использовать.
Sensio Labs Insignts и Scrutinizer — очень продвинутые инструменты, я пробовал на приватных проектах и упоминаю при случае. По открытию исходников — не я решаю, а позиция менеджмента — закрытое ПО.
Sensio Labs Insignts очень хорошо работает с симфони проектами, а Scrutinizer еще и по уязвимостям хорошо специализируется. Вместе с Php Inspections (EA Extended) — это просто без комментов =)
nazarpc: а можете ссылки в личку кинуть с результатами от Scrutinizer и Insignts — мне любопытно?
И поменьше рефлексии, вам комьюнити нужно — это мощная поддержка, в т.ч. моральная.
Сможете продуктивно работать с единомышленниками и собирать фидбек в виде issues/pull requests.
Ну а там видно будет взлетел проект и стагнировал — в любом случае вы в плюсе. Удачи!
Вы задали правильный вопрос, именно в него и упираются многие решения =)
И авторитаризм, если говорить о процессе разработки софта. Вы правы.
Я подозреваю, что для ФБ дешевле допилить Hack, чтобы:
— сохранить команду;
— сохранить работающие решения;
— уменьшить стоимость разработки и сопровождения;
Поэтому будут самые разнообразные проекты PHP/JVM, .NET/JVM, LLVM =)
Плюс когда мы с их рекрутерами общались в Декабре, они чётко обозначили Java + PHP в своих требованиях.
1) HHVM — поддерживает и PHP (слабая типизация) и Hack (стогая типизация). Поэтому всё своё (JVM — строгая типизация, поэтому нет полной совместимости).
2) JPHP — «We don’t plan to implement the zend runtime libraries», не для больших продакшн проектов. Да и HHVM выглядит привлекательнее, плюс мощные оптимизации c++ компиляторов.
Тут я своего мнения ещё не сформировал окончательно. Но я надеюсь, что примитивные и возращаемые типы перекочуют в PHP как можно быстрее.