Я помню выход PHP7: появились strict types, скалярные type hint-ы.

Мы начали двигаться в сторону языка со статической типизацией, но типизация не ушла в статику. Концептуально все осталась прежним мы запускаем программу и только в runtime узнаем, что где-то есть неправильный тип. Даже если мы везде явно проставим типы, все ошибки мы не поймаем и можем больно упасть в продакшене.

Всем привет! Это частичная расшифровка моего подкаста Между скобок разговоров обо всем, что связано с разработкой на PHP. В гостях у меня Валентин Удальцов, автор телеграм-канала Пых, который регулярно пишет о плюсах статического анализа.

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

Если вы решите углубиться в тему, советую эти видео:

• Обзор инструментов для аудита кода от Александра Новикова
• И мой недавний доклад, в котором я рассказал о первых результатах внедрения статического анализа в команде

Поехали!

Сергей Жук, Skyeng: Что вообще анализируют статические анализаторы? Они же не только про типы, да?

Валентин Удальцов, Пых: Статический анализ выходит далеко за пределы декларации типов в PHP. Типизация может быть очень многогранна: скажем, это может быть работа с иммутабельность и чистотой. То есть, мы можем гарантировать, что объект определенного класса не меняется в процессе его использования, на нем нет setter-ов.

Мы также можем следить за чистотой функции: смотреть, что она не обращается к IO.

В Psalm еще недавно добавили taint analysis: мы можем проследить данные от источника из внешней среды до какого-то уровня вглубь и понять, что все данные были так или иначе провалидированы. Тогда, с некоторой долей вероятности, у нас нет проблем с безопасностью. Вот еще одна задача, которую может решать статический анализ.

Сергей Жук, Skyeng: А ты вообще разбирался, как это работает? Если мой код не выполняется, получается, он парсится в абстрактное синтаксическое дерево и...

Валентин Удальцов, Пых: Есть статические анализаторы, которые используют autoloading композеровский те же PHPStan и Psalm. Phan по-моему, частично использует runtime, но дальше сам анализ происходит без выполнения.

В этом вся суть. В основе большинства статических анализаторов, речь не только про тройку, что я назвал, используется парсер, который написан на PHP Никитой Поповым. При помощи этого парсера код разбивается на токены, и мы можем анализировать вызовы, получать набор expression-ов, statement-ов, делать какие-то выводы о том, как данные протекают в процессе выполнения в этих участках кода.

Есть два этапа. На первом Psalm проходит весь код, который ты указал ему явно полностью. Традиционно это папка src и любые другие, которые ты перечислил. Он также заглядывает в vendor, если твой код использует вендорные классы. Это просто сбор данных: он все кэширует, трансформируя данные парсера Попова в некоторые свои сущности.

Потом, при следующих проходах, первый этап повторяется только для тех файлов и зависимостей, которые поменялись. За счёт этого Psalm работает достаточно быстро.

Второй этап это анализ. По умолчанию он проходит только в измененных файлах. Но можно форсировать полный анализ: тогда Psalm поднимет из кеша подготовленные на первом этапе данные и проведет рекурсивный анализ всего и вся.

Сергей Жук, Skyeng: Ты постоянно упоминаешь Psalm а почему не другие?

Валентин Удальцов, Пых: Да все просто. Когда я вообще что-то выбирал, то договорился на работе в Happy Inc., что начинаю новый проект и мы сразу включаем всё на максимум. Посмотрел, что чаще упоминают, сделал базовое сравнение фич. Phan не использовал composer autoloading, насколько помню. В PHPStan было больше плагинов. В Psalm была иммутабельность, еще какие-то вещи, частые релизы, сообщество, а человек, который его развивает, на оплачиваемой должности. Все это подкупило.

Выбор я сделал и не слежу, как развиваются альтернативы. Просто времени нет. Но Psalm до сих пор часто удивляет: скажем, с новым релизом может появить фича, про которую я знать не знал, что это можно проверять статически.

Бывает и так, что выйдет новый релиз, а там какая-то регрессия или на что-то не написан тест.

Естественно, приходится такое suppress-ить, писать issue. Мой лайфхак: если вы нашли проблему в любом пакете, который ставите, напишите todo, создайте issue, а в todo впишите ссылку на issue. Когда issue закроют, по его url вы найдете все места в коде, где нужно убрать suppress.

С Psalm я так и поступаю: не откатываю версию, я просто пишу suppress-ы и обязательно делаю тикет.

Сергей Жук, Skyeng: А как подсадить на статанализ команду? Люди ждут, что им сейчас всякие хитрые баги найдут, а в реальности все немного иначе.

Валентин Удальцов, Пых: У меня нет опыта внедрения Psalm на большом проекте с кучей людей. Этот момент я признаю. Мне помогло то, что я начинал писать проект один, хотел по полной обмазываться статическим анализом, и сделал это. А когда начали подключаться люди с других проектов, они были поставлены в существующие рамки. Конечно, поначалу я объяснял и показывал, но у нас небольшой техотдел. Так что не сказал бы, что адаптация других ребят заняла много времени.

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

Когда ты добавляешь инструмент в старый проект, там найдется миллион ошибок. Но ты говоришь анализатору: мы признаем, что это есть, но пока не обращаем на это внимание а вот когда мы пишем новое, рассказывай, где проблемы. Это baseline и постепенно, относительно него, разработчики учатся писать код с учетом статического анализа. При этом в Psalm есть несколько уровней, то есть инструмент максимально заточен, чтобы внедрять его постепенно.

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

Сергей Жук, Skyeng: Бывает, анализаторы ругаются на неверные PHP-доки, хотя сам код работает правильно. Да и ты говорил про баги, которые помечаешь todo-шками Есть ли тогда смысл добавлять статанализ наравне с тестами в CI?

Валентин Удальцов, Пых: Добавлять надо, иначе теряется смысл. Идея типизации в том, чтобы снизить энтропию, повысить детерминированность того, что мы пишем. А богатая типизация позволяет писать меньше тестов. Если мы знаем, что где-то есть тип, который возвращает в этом случае null, а в этом string, если мы точно знаем, в каких случаях что возвращается, то не понадобится писать тест, который это проверяет.

Статический анализ это полноценный этап CI, который пробегает до тестов.

Если у тебя типы неверные, что там тестировать? Ты в любом случае накосячил.

Что касается багов в Psalm, обычно это минорные вещи, не самая большая проблема. Если есть реальная проблема, мы формируем issue и костыльком в виде suppress или подсказки с todo-шкой это фиксим. При этом бывают нюансы, которые ты сразу не понимаешь, делаешь issue, а тебе отвечают: Да ты просто здесь вот это не так указал. И скидывают как правильно.

Сергей Жук, Skyeng: Ок, но для таких инструментов свой синтаксис надо учить. И твой код им обрастет. Как ты думаешь, в будущем это всё мигрирует в сам PHP?

Валентин Удальцов, Пых: Я смотрю на свой текущий проект. Он написан как бы не на PHP, а на PHP плюс Psalm. Но это всё-таки далеко от того, чтобы быть прям совсем другим языком. Это не как Haskell и PHP, например.

Что касается будущего, трудно сказать. Если код не типизирован, вероятность ошибки выше. Пока PHP как бы на двух стульях сидит: с одной стороны, позволяет mixed (и это иногда удобно), а с другой, мы так или иначе стремимся к типизации.

Сергей Жук, Skyeng: Ок, а что бы ты сказал человеку, который сейчас открыл IDE, создал новый проект и думает, добавлять статанализ или ну его?

Валентин Удальцов, Пых: Бизнес-логику, естественно, никакой статический анализ не проверит. А вот типы и все эти совершенные тупые ошибки снижаются процентов на 80. Да, в начале будет сложнее. Но в долгосрочной перспективе это профит. Статический анализ передвигает исправление багов ближе к началу разработки, а это снижает издержки на поддержку проекта.

Ведь всех бесят ошибки с продакшена, когда вместо expected string пришел int, null где-то появился или undefined index. Поэтому разработчик может взвесить все плюсы и минусы, понять, что благодаря статическому анализу вот такие совершенно глупые ошибки исключаются. А еще есть приятный бонус в виде дженериков.

Сергей Жук, Skyeng: А всё же есть какие-то минусы, каких-то кейсы, где вообще не надо использовать стат анализ?

Валентин Удальцов, Пых: Если проект реально большой, а команда привыкла полагаться на runtime издержки на интеграцию могут быть запредельными. Но все равно я бы советовал попробовать baseline внедрить, посмотреть, что как будет. Многие вещи надо в несколько этапов внедрять.

А если вы распиливаете большой монолитный сервис, и по какой-то причине продолжаете на PHP все делать, стоит попробовать.

Это не только хайп последних лет. Это реально полезно. Если мы полагаемся на runtime, то обязательно наткнемся на сложную ситуацию, что и поправить безумно дорого, и клиент готов уйти, и всё-всё очень плохо.

p.s. Найти другие выпуски подкаста вы можете здесь.

За последний год разработчики Vimeo писали код бэкенда на множестве языков PHP, Go, Ruby, Python, NodeJS, Java, C, C++ и немного на Rust.

В 2004 году мы начинали всего с одного: PHP. Это был идеальный язык для новых стартапов наподобие Vimeo. Интерпретатор PHP позволял предпринимателям быстро разрабатывать прототипы и имел большую стандартную библиотеку, позволявшую избавиться от мороки с повседневными задачами типа отправки писем и доступа к базам данных.

Большинство стартапов развалилось, однако некоторые из них, взявшие за основу PHP, по-прежнему были живы спустя десяток лет. Немногие из них добилась резкого роста, а в дальнейшем кое-кто из этих стартапов (самым заметный пример это Facebook) решил, что PHP является узким местом, и начал мигрировать с него. Для этого исхода было две серьёзные причины: производительность PHP и сложность поддержки больших кодовых баз PHP.


С точки зрения производительности PHP в 2014 году был медленнее, чем нужно, а массивы потребляли гораздо больше памяти, чем это было необходимо. Поддержка крупных кодовых баз PHP осложнялась ещё и отсутствием хороших инструментов статического анализа, способных массово распознавать баги.

С 2004 года за десять лет Vimeo вырос во много раз, и наша кодовая база PHP росла вместе с ним, но мы не выросли настолько, чтобы эти проблемы встали перед нами в полную силу. Однако когда Facebook публично отказался от использования PHP, некоторые разработчики решили, что PHP постепенно становится FORTRAN эпохи Интернета. Новая волна бэкенд-разработчиков начала планировать, как нам преобразовать 500 тысяч строк кода на PHP в набор лучше спроектированных, более производительных и удобных для тестирования сервисов на Go.

Какое-то время это казалось неизбежным, но мы так и не дошли до полного отказа от PHP. На то были очевидные причины: переписывание всей кодовой базы это затратный и подверженный ошибкам процесс. Однако была и ещё одна, менее очевидная причина: PHP стал лучше.

Слова PHP стал лучше не в полной мере описывают его преобразование. За последние шесть лет в два с лишним раза уменьшилось время выполнения кода на PHP, значительно выросло сообщество разработчиков и появилась популярная тенденция совершенствования кодовых баз на PHP (старых и новых) на основе выводов, сделанных исходя из статического анализа.

Для проникновения усовершенствований PHP в Vimeo потребовалось какое-то время. Сначала нам пришлось избавиться от старой версии PHP (5.4), работавшей в продакшене долгие годы уже после истечения её срока годности. Благодаря миграции на PHP 7 значительно ускорилась реакция бэкенда; кроме того, улучшенный синтаксис PHP 7 позволил нашим разработчикам писать чуть более чистый код с полной поддержкой типов возвращаемых значений и параметров.

PHP не прекратил обновляться выпущенная в конце ноября версия 8 принесла с собой множество усовершенствований на уровне языка, которые позволят нашим разработчикам выражать бизнес-логику более кратко. Мы планируем перейти на новую версию в начале 2021 года.

Статический анализ это круто

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

Иногда я тоже стрелял себе в ногу, работая с PHP, но решил не сдаваться, а создать инструмент, позволяющий повысить мою меткость. Так родился Psalm инструмент контроля типов для PHP на основе статического анализа.

Базовая функциональность Psalm приблизительно похожа на контроль типов в TypeScript, а также позаимствовала кое-какие идеи у созданного Facebook языка Hack (производного от PHP). Psalm сообщает разработчику, когда код на PHP может вызвать ошибку несоответствия типов в продакшене, а также когда логика непонятна. Кроме того, инструмент имеет дополнительную функциональность наподобие обнаружения неиспользуемых классов и методов, позволяя автоматически устранять многие найденные проблемы.

Использование Psalm в нашем конвейере CI в течение последних нескольких лет преобразовало подход к написанию кода на PHP в Vimeo: Psalm обеспечил нам уверенность в том, что можно вносить крупномасштабные изменения, не беспокоясь о том, что всё целиком сломается.

Эти изменения, некоторые из которых внесли в нашу кодовую базу современные стандартные кодинга на PHP, позволили избавиться от привкуса легаси если ты чувствуешь, что вносить изменения в код безопасно, то это уже не легаси.

Я создал Psalm для решения своих проблем, но когда мы выпустили его в open source, он помог помочь и проблемы множества других людей. Недавно Psalm помог нам выявить кучу уязвимостей защиты в нашей кодовой базе ещё до того, как ими могли воспользоваться злоумышленники.

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

Старый код необязательно является легаси

В середине 2000-х не существовало качественных ORM для PHP, поэтому мы создали собственное. К счастью, в PHP есть множество строительных блоков для создания простого ORM в стиле ActiveRecord, в том числе и с поддержкой MySQL, привязкой параметров запросов и магическими геттерами и сеттерами. Помогло нам и то, что этой задачей занялись по-настоящему умные инженеры.

Последнее крупное обновление нашего ORM было выпущено десять лет назад. В него вошли некоторые незначительные усовершенствования устранение багов, улучшенные типы и несколько новых фич, но базовая структура осталась неизменной.

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

В конечном итоге, ни одно из этих предложений не прижилось. Оказалось, что старый код может быть предпочительнее нового, если он отвечает следующим требованиям:

• Эффективно выполняет свою задачу
• Прост для статического анализа
• Хорошо протестирован
• Идиоматичен

К счастью, созданное нами ORM удовлетворяет всем четырём критериям.

Кроме того, сохранение надёжного старого кода даёт нам возможность сосредоточить усилия разработчиков на том, что приносит бизнесу материальную выгоду, и в соответствии с договором я обязан (но в то же время и рад) сказать, что в последнее время Vimeo находится на подъёме, выпустив множество отличных продуктов наподобие Vimeo Record.

PHP не обязан быть ужасным

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

Я считаю, что это возможно, и длительный успех Vimeo с PHP является доказательством того, что это отличный инструмент для быстро развивающихся компаний и в 2020 году.

Возрождение PHP убедило по крайней мере одного бывшего скептика. Мой коллега и давний критик этого языка однажды позвал меня в сторону и горячо поблагодарил за то, что я показал ему, что работа с PHP не обязана быть ужасной.

---

На правах рекламы

Эпичные серверы это виртуальные серверы для размещения сайтов от маленького блога на Wordpress до серьёзных проектов и порталов с миллионной аудиторией. Создайте собственный тарифный план в пару кликов, максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe!

Рады представить финальный мажорный релиз PhpStorm в этом году! Под катом подробный разбор всех изменений и новых возможностей.

• PHP 8: поддержка всех языковых функций, и штормовские атрибуты.
• PHPStan и Psalm можно использовать для подсветки ошибок в редакторе.
• Xdebug 3 с упрощённой конфигурацией, и новые фишки для отладки в IDE.
• HTTP-клиент теперь может запускать запросы Guzzle и экспортировать в cURL.
• Совместная разработка для работы над проектом с коллегами в реальном времени.
• Редактор научился рендерить диаграммы Mermaid.js, разделять экран перетаскиванием, и позволяет просматривать файлы не открывая их.
• Git stage поддерживается как альтернатива для changelists.
• В инструментах БД добавлен SQL для MongoDB.
• Tailwind CSS теперь тоже поддерживается.

PHP 8

PHP 8.0 выпущен. Большое спасибо всем контрибьюторам и менеджерам релиза!

PhpStorm 2020.3 поддерживает все последние изменения языка. Давайте рассмотрим, что доступно и как это использовать в IDE.

Версия языка в статусбаре

Теперь в статусной строке всегда отображается текущая версия PHP проекта. Оттуда же можно переключить версию.



Если переключатель не активен, это означает, что ограничение на версию PHP задано в composer.json.

Именованные аргументы

В PHP 8 аргументы функций и методов могут передаваться путем указания имени параметра. Вызовы теперь автоматически задокументированы, а необязательные параметры стали необязательными в полном смысле слова.

С помощью квик-фикса Add name identifiers можно добавить имена к аргументам:



Опечатки или ошибочные имена аргументов подсвечиваются:



Если передаваемое значение совпадает со значением параметра по умолчанию, то его можно смело удалить:



Вместо массива options для передачи набора параметров можно использовать именованные аргументы, просто передавая только необходимые. Аргументы, передаваемые таким образом, в отличие от элементов массива, являются типобезопасными.

Атрибуты

Атрибуты это новый, структурированный способ указания метаданных в PHP вместо комментариев PHPDoc.

Чтобы создать атрибут, надо объявить класс и добавить маркер #[Attribute]. Здесь PhpStorm поможет с подсветкой, автодополнением кода, поиском использований, рефакторингами и прочим.



Сам PHP проверяет валидность атрибутов только при вызове ReflectionAttribute::newInstance(). А если не обращаться к атрибутам через Reflection, то они полностью игнорируются, чтобы не загружать лишние классы и не создавать объекты.

А вот PhpStorm провалидирует все в редакторе, не запуская Reflection API. При этом проверяются следующие правила:

• Указанный класс действительно может быть атрибутом.
  
  
  
• Данный атрибут применяется только в разрешенных местах: класс, свойство, метод, параметр, функция или константа класса.
  
  
  
• Атрибут повторяется только в том случае, если он объявлен с флагом Attribute::IS_REPEATABLE.
  
  
  

Вот атрибуты в действии с Symfony:

---

Штормовские атрибуты PHP 8

Несколько атрибутов доступны в PhpStorm 2020.3 из коробки в неймспейсе \JetBrains\PhpStorm\.

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

А вот если вы дополнительно используете другие инструменты статического анализа и не хотите получать ошибок типа Class not found, то тогда, возможно, стоит добавить пакет атрибутов JetBrains/phpstorm-attributes как зависимость в composer.json.

#[Deprecated]

Используйте этот атрибут как PHPDoc-тег @deprecated, чтобы пометить методы, классы или константы классов, которые будут удалены в будущем.

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

Давайте посмотрим на реальный пример. В недавно выпущенном Symfony 5.2 метод \Symfony\Component\DependencyInjection\Alias::setPrivate() объявлен устаревшим. Если там добавить атрибут #[Deprecated], то можно упростить миграцию.

#[Deprecated(   reason: 'since Symfony 5.2, use setPublic() instead',   replacement: '%class%->setPublic(!%parameter0%)')]

#[ArrayShape]

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

Синтаксис вот такой:

#[ArrayShape([// key => type,   key1 => int,   key2 => string,   key3 => Foo,   key3 => App\PHP 8\Foo::class,])]function functionName(...): array

Тип может быть указан как строка или как ссылка на класс в виде FQN строки или константы ::class.



Массив, который определяет форму, можно вынести в константу и переиспользовать:

const  MY_ARRAY_SHAPE = [];#[ArrayShape(MY_ARRAY_SHAPE)]

В PhpStorm мы уже проаннотировали атрибутом #[ArrayShape] некоторые стандартные функции PHP, например parse_url().

К счастью, синтаксис однострочных атрибутов обратно совместим. То есть, если записать #[ArrayShape] в одну строку в проекте на PHP 7, то интерпретатор PHP воспримет эту строку как комментарий.

В отличие от интерпретатора PHP, PhpStorm все равно будет анализировать атрибуты! Так что, даже если ваш проект работает на PHP 7.4 или ниже, вы все равно получите пользу от добавления #[ArrayShape].

#[Immutable]

Неизменяемые объекты не могут быть изменены после инициализации или создания. Их использование делает состояние программы более предсказуемым и облегчает отладку.

Атрибутом #[Immutable] можно пометить весь класс или конкретные свойства, чтобы показать, что они не могут быть изменены.

PhpStorm будет проверять использование таких объектов и свойств и подсвечивать попытки изменения.



Изменение свойства по умолчанию разрешено в конструкторе, но можно также разрешить и в методах private/protected. Это делается с помощью констант CONSTRUCTOR_WRITE_SCOPE, PRIVATE_WRITE_SCOPE, PROTECTED_WRITE_SCOPE, передаваемых в конструктор #[Immutable].

#[Pure]

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



Если функция помечена как чистая, но в ее теле есть попытка изменить что-то за пределами из внешнего скоупа, то PhpStorm подсветит небезопасный код.



Все стандартные чистые функции PHP уже помечены этим атрибутом в PhpStorm.

#[ExpectedValues]

С помощью этого атрибута можно указать, какие значения функция принимает в качестве параметров, а какие может возвращать.

Это практически то же самое, что делает expectedArguments() в .phpstorm.meta.php. Разница лишь в том, что мета-версия, скорее, вспомогательная, а атрибут жестко указывает, что других возможных значений нет.

Например, рассмотрим функцию count:

count ( array|Countable $array_or_countable [, int $mode = COUNT_NORMAL ] ) : int

Еe второй аргумент целое число, но на самом деле это не произвольное целое число, а одна из констант COUNT_NORMAL или COUNT_RECURSIVE.

Вот как атрибут #[ExpectedValues] улучшит ситуацию:



То есть появилось автодополнение, а если передано что-то другое, то подсвечивается ошибка.

Еще один пример #[ExpectedValues]

Возьмем хелпер response() из Laravel. В качестве второго параметра он принимает статус код HTTP.

Есть две проблемы

• Нет автодополнения с возможными кодами
  
• Нет проверки правильности значения в редакторе
  

Давайте исправим это, добавив атрибут #[ExpectedValues(valuesFromClass: Response::class)]

#[NoReturn]

Некоторые функции могут приводить к остановке выполнения скрипта. Если отметить такие функции как точки выхода атрибутом #[NoReturn], то улучшится анализ потока управления.

#[Language]

Этот атрибут можно добавить к строковым параметрам, в которых ожидается текст на каком-либо языке, например RegExp, SQL, DQL и так далее.

Для аргументов появится подсветка и дополнительные возможности.

---

Вернемся к новым возможностям PHP 8.

Объявление свойств в конструкторе

Обычные свойства можно преобразовать в promoted или обратно с помощью квик-фикса Convert to promoted property.



PhpStorm гарантирует, что свойства используются только способом, разрешенным в PHP 8:

• Можно декларировать свойства только в конструкторе.
  
• Нельзя объявлять в абстрактном конструкторе.
  
• Нельзя объявлять свойство variadic таким образом.
  
• Свойство не может иметь тип 'Callable'.
  
• Не допускается переопределение свойства.
  

Если свойство объявлено новым способом, но в теле конструктора осталась инициализация, то PhpStorm предложит ее удалить.

Выражение match

Новое выражение похоже на switch, но использует строгое сравнение и может быть присвоено переменной или возвращено.

PhpStorm определяет, может ли блок switch быть переделан в match, и сделает это автоматически с помощью квик-фикса по нажатию Alt+Enter:



Может быть трудно увидеть неправильное использование нового выражения, поэтому PhpStorm подсветит все ошибки.




Будут обнаружены дублирующиеся значения в условиях:



Выражение match с одной веткой и веткой по умолчанию может быть безопасно заменено на тернарное выражение.



А если осталась только ветка по умолчанию, то соответствие match вообще не понадобится.



Наконец, если в разных ветвях одинаковые тела, они могут быть объединены.

Оператор nullsafe

Вместо кучи условий с проверкой на null теперь можно использовать цепочку вызовов с новыми оператором ?->.

PhpStorm проверит правильность использования оператора:

Висячая запятая

Теперь допустимо добавлять запятую после последнего аргумента при вызове функций и в списке замыканий use.

Non-capturing catches

В PHP 8 можно ловить исключение в catch-блоке без переменной.

Выражение throw

Бросать исключения теперь можно в стрелочных функциях и в коротких операторах ??, а также в тернарном ? :.



Можно использовать сокращение thr и нажать tab это live template.

Константа ::class на объектах

Раньше, чтобы получить FQN объекта, нужно было использовать функцию get_class(). В PHP 8 вызов get_class($object) можно смело заменить на $object::class.

Собственно, по нажатию Alt+Enter такую замену и можно сделать. Неправильное использование константы ::class PhpStorm подсветит.

Новые функции для строк: str_contains(), str_starts_with(), str_ends_with()

How do I check if a string contains a specific word? самый просматриваемый вопрос по PHP на Stack Overflow. В PHP 8 есть четкий ответ на этот вопрос: использовать функцию str_contains().

PhpStorm 2020.3 находит вызовы strpos(), которые можно заменить на str_contains():



Есть также новые str_starts_with() и str_ends_with() для определения того, начинается или заканчивается ли строка определенной подстрокой. PhpStorm подсвечивает, где вызовы substr() можно заменить новыми альтернативами:

Reclassified engine warnings

В PHP 8 для многих ошибок был пересмотрен тип бросаемого предупреждения. А именно, вместо Notice во многих случаях будет Exception или Type Error.

В PhpStorm в связи с этим некоторые инспекции имеют два разных уровня severity: для PHP 8 и для более старых версий.



Это все из наиболее заметного по PHP 8. Есть еще целая куча изменений помельче, которые будут видны при обновлении на PHP 8.

Поддержка Psalm и PHPStan

Оба статических анализатора можно использовать в PhpStorm 2020.3 для подсветки проблем непосредственно в редакторе.



Если PHPStan или Psalm добавлены как зависимости в composer.json, то рядом с ними будет значок гаечного ключа, открывающий настройки инструмента.



Оттуда можно перейти к настройкам инспекции и включить подсветку в редакторе. Это делается выбором соответствующей инспекции в списке PHP | Quality tools в Settings/Preferences | Editor | Inspections.

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



Тут же можно указать путь к конфигурационному файлу и настроить аргументы командной строки.

PHPStan может работать без конфигурационного файла, а для Psalm он требуется обязательно. Если в корневом каталоге есть psalm.xml или phpstan.neon, PhpStorm подтянет их автоматически.

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

Аннотации

Все псалмовские аннотации @psalm-* теперь корректно подсвечиваются в редакторе. Но вообще, теперь можно смело убирать префикс @psalm- из тегов, то есть @psalm-return -> @return и @psalm-param -> @param.

Поддержка типов

Добавили поддержку некоторых типов Psalm и на основе информации из тегов улучшили наш вывод типов. Это сделало более точными проверки, генерацию кода и автодополнение.

Псевдотипы
Поддерживаются псалмовские псевдотипы, такие как scalar, numeric и т. п.



Константы в типах
Пожжерживаются объединения констант и указание через * в тегах param и var.



Тайпхинты для массивов
Описания массивов array<array-key, Type> тоже поддерживаются, в том числе вложенные.



Дженерики и @tempate
Поддержка дженериков фича для продвинутых пользователей, у которой нет полной корректной спецификации и много граничных случаев. Тем не менее мы решили реализовать базовую поддержку для @template на основе синтаксиса Псалма, чтобы посмотреть, как это будет использоваться.

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

Эта поддержка дженериков является очень базовой, ее можно считать экспериментальной. Хотим понять, как это будет использоваться и что нужно реализовать в первую очередь. Будем рады обратной связи, особенно в виде реальных примеров использования в наш трекер.

Xdebug 3

Обновился популярный отладчик для PHP, теперь он значительно быстрее в работе и проще в настройке. Более подробно об Xdebug 3 читайте в документе Upgrade guide.

Чтобы сконфигурировать Xdebug 3, теперь достаточно одной опции xdebug.mode (например так XDEBUG_MODE=debug).

Также был изменен дефолтный порт Xdebug: вместо 9000 теперь 9003. Чтобы упростить миграцию, PhpStorm по умолчанию слушает оба порта. Настройки портов и другие опции для Xdebug находятся в Preferences/Settings | Languages & Frameworks | PHP | Debug.

Улучшения отладчика

Возможности по отладке в PhpStorm расширились двумя новыми фишками.

Интеркактивные хинты
Теперь в отладочном режиме вывод переменных можно развернуть, чтобы увидеть все поля. Тут же можно и изменить значения.



Inline Watches
В предыдущих версиях можно было добавить переменную или выражение в список watch и наблюдать, как меняется значение по шагам.

В PhpStorm 2020.3 можно добавлять вотчи непосредственно к контексте, и они будут отображаться рядом с кодом.

Нажмите Add as Inline Watch в попапе на хинте.


Или нажмите Add Inline Watch в контекстном меню редактора.


Или выделите переменную и в контекстном меню выберите Add Inline Watch.

Подсветка и переименование переменных в Twig

Выберите переменную или поместите на нее курсор, и все ее использования в шаблоне будут подсвечены. А чтобы переименовать все вхождения, нажмите Shift + F6.

Совместная разработка Code With Me

В PhpStorm 2020.3 встроен плагин Code With Me новый инструмент JetBrains для совместной разработки и парного программирования. С помощью него можно расшарить открытый проект с другими пользователями и работать над ним вместе в режиме реального времени. Подробнее про Code With Me в этих постах.

HTTP-клиент

Интеграция Guzzle с HTTP-клиентом в PhpStorm

Guzzle один самых популярных HTTP клиентов для PHP. Представьте, что где-то в коде есть HTTP-запрос и хочется его потестировать, не запуская сам код. Раньше пришлось бы копировать все параметры вручную.

PhpStorm 2020.3 позволяет конвертировать простые запросы Guzzle в файлы .http. Если запрос поддерживается, то рядом с ним появится иконка. Нажав на нее, вы откроете новый scratch-файл с правильным URL, параметрами запроса, методами, заголовками, телом.



Теперь из редактора запрос можно запустить и поиграться с ним, а затем сохранить его как http-файл в проекте.

Больше об HTTP-клиенте в видеообзоре.

Копировать HTTP-запрос в cURL

Чтобы экспортировать HTTP-запрос в cURL-строку, нажмите Alt+Enter на запросе в редакторе и выберите Convert to cURL and copy to clipboard. Теперь его можно вставить в терминал, документацию или любой инструмент тестирования API.

Редактор

Улучшения для Markdown

Для описания диаграмм и графиков можно использовать синтаксис Mermaid.js в markdown-файлах. PhpStorm теперь умеет рендерить превью для них прямо в редакторе. Включается в Preferences/Settings | Languages & Frameworks | Markdown.



Еще теперь можно переформатировать содержимое файлов .md в соответствии с популярными стилями. Делается нажатием L / Ctrl+Alt+L.

Настраивается в Preferences/Settings | Editor | Code Style | Markdown.



И наконец, если нажать кнопку Auto-Scroll Preview в правом верхнем углу редактора, то прокрутка превью и текста будет синхронизирована.

Улучшена проверка орфографии и грамматики

Опечатки и грамматические проблемы теперь можно исправлять намного быстрее:

• Во-первых, во всплывающем окне появится объяснение ошибки.
  
• А если нажать Alt+Enter на подсвеченном тексте, то варианты замены будут предложены наверху, а не спрятаны в подпункт, как раньше.
  

Сплит редактора перетаскиванием

Чтобы открыть несколько файлов бок о бок, просто перетащите вкладку в нужный угол экрана.



Есть еще один способ открыть файл в сплит-режиме Shift+Enter.
Комбинацию можно нажать на выбранном файле в Project view или в результатах поиска по файлам.

Вкладка предпросмотра

Если нужно быстро просмотреть файлы, то теперь не обязательно открывать каждый в отдельной вкладке. Можно использовать новую вкладку Preview tab.

Чтобы включить ее, нажмите на шестеренку в Project view и выберите Enable Preview Tab и Open Files with Single Click.



Еще можно просматривать файлы нажатием пробела в Project view, не открывая их.

IDE

Улучшения для Search Everywhere

Результаты сгруппированы по релевантности:


Можно делать простые математические операции и не открывать гугл калькулятор:


Можно искать по истории Git:

Автоматическое переключение на светлую или темную тему

В Preferences/Settings | Appearance & Behavior | Appearance | Theme выберите Sync with OS.

Новый набор горячих клавиш для macOS

Альтернативная раскладка горячих клавиш для macOS минимизирует использование функциональных клавиш, чтобы не надо было растягивать руку на всю клавиатуру при совершении основных действий. Например, вместо Fn+Shift+F6 для Rename рефакторинга используется ++R.

Слова вместо иконок для горячих клавиш macOS

Можно сделать так, чтобы вместо иконок типа отображались слова Alt, Cmd и т. п.

Включается в секции Registry опцией ide.macos.disable.native.shortcut.symbols. Чтобы получить доступ к реестру, используйте Find Action Cmd+Shift+A и напишите там Registry.

Установить PhpStorm как приложение по умолчанию для разных файлов

В Preferences | Settings / Editor / File Types нажать Associate file types with PhpStorm. В диалоговом окне выберите расширения для файлов, и они будут открываться в PhpStorm.

На macOS требуется перезагрузка.

Шаблоны могут генерировать несколько файлов

Можно одновременно сгенерировать сразу несколько файлов, например скелет для модуля или комбо контроллер-вью.

В Preferences / Settings | Editor | File and Code Templates нажать на , чтобы создать новый шаблон, а затем нажать на иконку Create Child Template File .

В поле File name можно использовать переменные типа ${NAME}.



А вот пример того, как сгенерировать контроллер и шаблон в Symfony:

Поддержка Git stage

Включить можно чекбоксом Enable staging area в Preferences/Settings | Version Control | Git.

В окне инструментов Commit (Cmd+0 / Alt+0) появятся две группы файлов: staged и unstaged.

Чтобы добавить файл в staged, нажмите на + напротив него.



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

Инструменты БД

PhpStorm из коробки включает в себя возможности DataGrip, которые охвачены в обзоре релиза DataGrip 2020.3 от наших коллег.

SQL для MongoDB

Теперь можно использовать SQL-запросы к MongoDB. PhpStorm 2020.3 поддерживает SELECT-запросы с JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, OFFSETи всеми функциями MongoDB кроме map, reduce, filter и let. Подробнее в блог-посте.

Веб

Как всегда, в PhpStorm входят все обновления из WebStorm 2020.3. Наиболее примечательной является поддержка Tailwind CSS.

Tailwind CSS

PhpStorm дополняет классы Tailwind в HTML-файлах и после директивы @apply. А также предоставит автодополнение псевдо-классов.



Если навести указатель на класс в HTML и CSS файлах, то отобразится предпросмотр полученного CSS. Предпросмотр также доступен при автодополнении кода, во всплывающем окне документации F1 / Ctrl+Q.



PhpStorm поддерживает настройки из tailwind.config.js. Например, если определить тему с новыми цветами, то во всплывающем окне автодополнения будут созданные классы с именем кастомного цвета.

---

Скачать PhpStorm 2020.3 можно на странице Whats new.

А вот видеоролик (на английском) с демонстрацией главных фич релиза:


На этом всё на этот раз. Будем рады вопросам, пожеланиям, баг-репортам и просто мыслям в комментариях.