Следует ли использовать в методах значение по умолчанию null. Если нет, то почему?

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

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

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

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

⌨️ Топ-вакансий по PHP за неделю

Senior Backend Developer (PHP) — 330 000 —‍ 420 000 ₽ удалёнка (Москва)

PHP разработчик/Backend developer — до 270 000 ₽, Удалёнка (Москва)

PHP Developer — до 450 000 ₽, Удалёнка (Москва)

PHP-разработчик — от 230 000 ₽., Удалёнка

➡️ Еще больше топовых вакансий — в нашем канале PHP Jobs

🚀 Нативные уведомления в Laravel desktop-приложении с NativePHP

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

Быстрая настройка:

composer require nativephp/electron

и пример:

Notification::title('Привет!') ->message('Задача выполнена.') ->show();

👉 Подробнее читайте в статье.

🧹 Автоматический уборщик антипаттернов в PHP

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

Промпт:You are a seasoned «PHP Cool Developer,» renowned for your ability to identify and eliminate anti-patterns in PHP code. Your expertise lies in spotting duplication, unnecessary nesting, inefficient allocations, and dependency cycles. Your goal is to analyze a given PHP code snippet and provide a detailed report highlighting these anti-patterns, along with concrete suggestions for improvement.

Here is the format you will use to analyze the code and provide your recommendations:

#

Anti-Pattern Analysis

1. Duplication

 Description: (Explain if duplication exists, where it is located, and why it's problematic)

Recommendation: (Provide specific code changes or refactoring steps to eliminate the duplication)

### 2. Unnecessary Nesting

 Description: (Explain if unnecessary nesting exists, where it is located, and why it's problematic)

Recommendation: (Provide specific code changes or refactoring steps to reduce nesting)

### 3. Inefficient Allocations

 Description: (Explain if inefficient allocations exist, where they are located, and why they are problematic)



Recommendation: (Provide specific code changes or alternative approaches to improve allocation efficiency)
 
### 4. Dependency Cycles
 Description: (Explain if dependency cycles exist, which packages are involved, and why they are problematic)

Recommendation: (Provide specific refactoring steps to break the dependency cycle, potentially involving interface extraction or dependency inversion)

## Summary of Improvements
(A concise summary of all the identified anti-patterns and the proposed solutions)

Here is the PHP code you are tasked with analyzing: [ВСТАВЬТЕ ВАШ КОД СЮДА]

Промпт не просто ругается — он объясняет, где именно в коде проблема, почему она опасна или неудобна, и как её устранить с помощью конкретных шагов или рефакторинга.

Библиотека пхпшника #буст

How to: создание MCP-сервера с помощью Symfony

Model Context Protocol (MCP) открывает новые горизонты для интеграции ИИ с внешним миром. Если вы работаете с большими языковыми моделями (LLM), вы наверняка столкнулись с их ограничениями — они не могут напрямую взаимодействовать с внешними сервисами или базами данных. Но с помощью MCP это становится возможным!


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

🔗 Читать статью

Библиотека пхпшника #буст

💥 Холивар: Многотенантность — одна база данных или несколько?

Сколько раз вы сталкивались с этим вопросом при проектировании SaaS-приложений или подобных? Один БД или несколько? Давайте разберёмся.

🏢 Одна база данных для всех
Все данные в одной базе, где для каждого клиента создаются отдельные схемы или таблицы.

Плюсы:
🔸 Один сервер, одна база — удобно.
🔸 Меньше затрат на инфраструктуру.

Минусы:
🔹 Проблемы с производительностью при увеличении количества клиентов.
🔹 Сложности с масштабированием и резервным копированием.

🏠 Несколько баз данных для каждого клиента
Каждому клиенту — отдельная база данных.

Плюсы:
🔸 Полная изоляция данных.
🔸 Лёгкость в управлении большими объёмами данных.

Минусы:
🔹 Сложности с миграциями и обновлениями.
🔹 Увеличение затрат на инфраструктуру.

💬 А как вы решаете этот вопрос? Поделитесь своим опытом в комментариях!

Библиотека пхпшника #междусобойчик

🧠 Asymmetric Visibility в PHP 8.4: Новый способ управления доступом к свойствам

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

🔑 Что такое Asymmetric Visibility?
Теперь можно задавать разные уровни видимости для геттеров и сеттеров свойств. Например, вы можете позволить свойству быть доступным для чтения из внешнего мира, но ограничить его изменение только внутри класса или его подклассов. Это позволяет вам лучше контролировать доступ к внутренним данным объекта.

Вот как выглядит синтаксис:

[GETTER_VISIBILITY] [SETTER_VISIBILITY(set)] [TYPE] $propertyName;

Пример:

protected private(set) string $title;

Это означает, что свойство $title можно читать публично (через геттер), но изменять только внутри класса.

⚙️ Как это работает?
В PHP 8.4 вы можете установить видимость для получения (геттера) и изменения (сеттер) свойств отдельно. Например, можно настроить так, чтобы свойство было доступно для чтения всеми, но изменять его могли только методы класса или его наследники. Это улучшает инкапсуляцию, позволяя скрывать внутренние изменения данных, но предоставлять доступ к их чтению.

🔍 Когда это полезно?
Такая возможность особенно полезна в ситуациях, когда необходимо скрыть детали реализации объекта, но при этом предоставить доступ к его состоянию. Например, если нужно разрешить чтение информации, но не позволять её изменять извне, или наоборот — запретить доступ к данным, но предоставить возможность их обновления через методы класса.

⚠️ Ограничения и нюансы:

🔸 Только для типизированных свойств: Ассиметричная видимость работает только с типизированными свойствами.
🔸 Более строгая видимость для сеттеров: Видимость сеттера должна быть такой же или более строгой, чем у геттера.
🔸 Финальные свойства: Если свойство имеет приватный сеттер, оно считается финальным и не может быть переопределено в подклассе.

💡 Почему это важно?
Asymmetric Visibility — это полезный инструмент для повышения гибкости и безопасности данных в приложениях. Он позволяет ограничить возможность изменения состояния объекта, сохраняя при этом доступность данных для чтения. Это помогает минимизировать риски и улучшить архитектуру вашего кода.

👉 Читать статью

💻 Подборка новостей по PHP за неделю:​

🔹 JetBrains Junie для PhpStorm — новая эра агентных IDE: Junie способен выполнять объёмные задачи самостоятельно, выводя продуктивность на новый уровень.

🔹 Laravel 12.19 — добавлены атрибут UseEloquentBuilder, каст AsFluent, middleware FailOnException для очередей, улучшенные тестовые ассерты и другие нововведения.

🔹 Filament v4 Beta — переработанный интерфейс, повышенная производительность, больше контроля при создании интерфейсов. Бета-версия уже доступна для тестирования.

🔹 Symfony 16–22 июня — активная разработка Symfony 7.4 и 8.0: добавлена интеграция с FrankenPHP, удаляются устаревшие функции, улучшена гибкость контроллеров.

Библиотека пхпшника #свежак

Каким будем массив $b после выполнения кода?

📏 Единый стиль форматирования кода: как улучшить использование скобок и фигурных скобок в PHP

В статье предлагается новый подход к оформлению синтаксиса в PHP, который основывается на логике языка, а не на исторических привычках из других языков программирования, таких как C или Java. Цель — создать стиль, который будет унифицированным, систематичным, последовательным и лёгким для запоминания.

🔑 Что предложено?
Унификация: одна и та же правило применяется ко всем соответствующим конструкциям — будь то функции, управляющие структуры или вложенные выражения.
Системность: каждое правило следует прямо из синтаксической структуры, а не из лексической категории (ключевое слово, идентификатор и т. д.).
Последовательность: одинаковое обращение с конструкциями без произвольных исключений.
Лёгкость запоминания: устранение контекстных различий и эстетических отличий, не имеющих функционального значения.

📚 Как это работает?
Нет пробела перед открывающимися скобками: Например, if($x) и while($y) — это всегда одно правило, независимо от того, является ли конструкция управляющей или функцией.
Открывающие фигурные скобки всегда на той же строке, что и управляющая структура: Например, function foo() { или if($x) {.
Закрывающие фигурные скобки на новой строке, выровненные с началом блока.

🚫 Почему стоит отказаться от исторических конвенций?
Ранее использованные в таких стандартах, как PSR-2 и PSR-12, подходы взяли за основу стиль, присущий языкам, подобным C, что ведет к путанице и необходимости запоминать исключения. Например, скобки в функциях и управляющих конструкциях должны располагаться по-разному, хотя структура этих конструкций схожа. Эти отличия не улучшали читаемость кода, а наоборот, только увеличивали когнитивную нагрузку.

🔥 Преимущества нового подхода:
Упрощённое восприятие кода.
Совместимость с инструментами автоматического форматирования, такими как PHP-CS-Fixer или линтеры.
Чистый и вертикально структурированный код, который легче воспринимать.

📈 Специальные случаи: if/elseif/else и try/catch/finally
Предлагается установить правило, что все блоки (например, if, elseif, else, try, catch, finally) должны начинаться с новой строки после закрывающей фигурной скобки предыдущего блока. Это улучшает структуру и читабельность кода, делая его более понятным и логичным.

💡 Советы для новых конструкций:
Стрелочные функции (fn): не ставить пробел между fn и открывающей скобкой.
Тернарные выражения (? :): использовать скобки для сложных вложенных выражений и ставить пробелы вокруг ? и :.

👉 Читать статью