PHP ломается не в синтаксисе, а в мелочах: 7 мест, где прячется баг

PHP ломается не в синтаксисе, а в мелочах: 7 мест, где прячется баг

За неделю в репах я бы первым делом проверял не «сложную архитектуру», а простые провалы: типы, границы, null, таймзоны, массивы, сравнения, побочные эффекты.

— == вместо ===: строка "0" и число 0 ведут себя слишком дружелюбно.
— Неявные приведения: null, пустая строка и 0 валиваются в одну корзину, если не поставить явную проверку.
— Мутируемые массивы и объекты: передали ссылку в сервис — и получили изменение не там, где ожидали.

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

Второй слой — side effects. Метод должен либо считать, либо менять состояние, но не делать всё сразу. Когда в одном месте и валидация, и запись, и отправка события, и преобразование данных, тесты начинают врать, а баги — прятаться в соседнем вызове.

Лучший чек перед merge простой: включить строгие сравнения, явно обработать null и даты, а все эффекты вынести за границу функции. Там, где код «почти работает», PHP обычно и оставляет сюрприз.