Разбор вызовов функций в PHP

Это звенья одной цепочки: HipHop -> HHVM -> Hack

HipHop: компилим бинарник через трансформацию исходников (экономия ресурсов, почти мгновенные результаты)

HHVM: свой интепретатор PHP, более производительный. Но это, скорее всего, переходная платформа, т.к. она поддерживает Hack. Обратная совместимость будет развиваться силами комьюнити, ФБ будет дальше развивать Hack.

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

Вообще ожидайте процесс перетаскивания фич Hack в PHP =)

Разбор вызовов функций в PHP

Да пишите вы код который легко читать и работает

Это вполне сочитается с оптимизацией кода, с оговоркой что лучше это делать на этапе ревью кода.

Разбор вызовов функций в PHP

У них другие цели — в первую очередь строгая типизация. Без нее поддержка больших проектов на PHP стоит очень дорого.

Разбор вызовов функций в PHP

Вот прямо в IDE.

Нестандартная оптимизация проектов на PHP

Это я увлекся просто, сорри. Пока писал что в случае класс лоадера это неважно, Вы уже ответили.

Нестандартная оптимизация проектов на PHP

В вашем комменте был include, без once…

Нестандартная оптимизация проектов на PHP

require_once(...) попробуйте, или логика именно на инклюдах?

Нестандартная оптимизация проектов на PHP

Кейс, кстати, часто встречается.

По моим наблюдениям, разработчики, как правило, понимают ООП как наследование и в лучшем случае добавить интерфейсов. Причём, если нет наследования (IoC, composition) то многих это ставит в ступор.

По поводу практик: вот шикарная книга (Patterns of Enterprise Application Architecture) — можно выбрать те паттерны, которые вам подходят больше всего.

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

Когда начнёте формализоать, придётся повоевать.

Мы просто решили: вот плагин, смотрите на что жалуется, чините и обучайтесь. Код должен быть «зелёным».

Если есть жалобы от анализатора, сразу отправляем на доработку. НО легаси код вычищают архитекторы, попутно оставляя todo и deprecated.

На гит переезжаем по-проектно и с ним гораздо комфортнее организовывать хуки — в целом у нас похожий подход.

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

Платформа не даёт таких инструментов, плагин может только экспортировать инспекции и аста-лависта. Второй момент — я немного параноик на тему сбора статистики плагинами от стороннего вендора.

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

В таких случаях можно подавить ложные срабатывания на уровне выражения или всего файла. Здесь есть информацияо том, как это делается.

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

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

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

О, расскажите потом (что отключили, что оставили)?

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

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

А можете рассказать, чем вы пользуетесь для статического анализа и как?

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

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

Забивайте :)

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

Fesor очень хорошо ответил, мне нечего добавить

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

Пока там нет инлайн-переменных, то разницы нет.

Если строка заключена в одинарные кавычки, то PHP не будет даже искать переменные (и спец. символы тоже) внутри — это главный нюанс. Теоретически объявление такой строки быстрее.

Я правда не помню, что происходит внутри APC, там разница будет минимальна.

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

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

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

Ваша правда, Фибиан об этом писал.

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

Остальные типы (массивы, классы и интерфейсы), типо-зависимые операции сравнения и поиска — часть языка и родного API.