Мнение о PSR-1: Базовый стандарт написания кода

После прочтения PSR-1 возникли некоторые мысли, о которых хотелось бы поведать сообществу программистов с целью получения рассказов о вашем опыте.


PSR-1: Базовый стандарт написания кода – стандарт, которые рекомендует правила оформления и написания кода. Оформление – как писать код, а написание – что писать.

Подтекст PSR-1 говорит о том, что не надо использовать смешивание кода и логических заключений кода. Немного не понятно выразился, но далее вы поймете, что PSR-1 не рекомендует писать класс, выводить на экран и заниматься инициализацией свойств в одном файле.

Все PHP файлы должны использовать либо <?php, либо <?=. Тут все очевидно и понятно, первый тег говорит об объявлении секции php кода, а второй – краткая запись <?php echo, то есть вывода.

Файлы также должны быть в кодировки UTF-8 без BOM, что вполне логично. Были как-то случаи в проекте, где было несколько программистов. Так вот, там один как-то умудрялся вставлять BOM символ и из-за этого парсинг файлов ломался.

Тут же говорится, что не рекомендуется использовать несколько побочных эффектов (side effects). С переводом у меня не всегда все ладно... То есть мы не можем взять и написать в файле:

<?php
// side effect: change ini settings
ini_set('error_reporting', E_ALL);

// side effect: loads a file
include "file.php";

// side effect: generates output
echo "<html>\n";

// declaration
function foo()
{
    // function body
}

Ну тут момент крайне спорный. Хотя стандарт рекомендует использовать автозагрузчик по своим стандартам PSR-0 и PSR-4. С одной стороны да, но может же быть инициализация приложения в единой точке входа. Короче, момент сомнительный. В том же самом Yii2 не соблюдается этот подход... Я бы не обращал внимания именно на эту рекомендацию.

Переходим в раздел имения классов и пространств имен (namespace). Тут я согласен, что файл класса должен содержать только этот класс, что класс должен находиться в пространстве имен. Именование классов должно быть в формате StudlyCaps. Мы не будем рассматривать варианты написания кода для версий PHP < 7.0, так как там есть свои нюансы, а востребованность версий ниже достаточно мала.

Константы мы именуем в верхнем регистре, разделяя слова нижним подчеркиванием DATE_APPROVED. Тут все логично и понятно, смысла именовать их похоже на свойства или переменные – нет. Надо четко различать константы от свойств.

А вот с именованием свойств я не согласен с рекомендаций. PSR-1 рекомендует использовать один из форматов: $StudlyCaps$camelCase, или $under_score. Я не очень люблю разношерстность кода и полагаться на мнение каждого программиста. Лично я, наверное как и многие программисты, считаю, что использовать надо лишь один стиль, и он должен быть $camelCase. Причем стандарт хитрый, он говорит о том, что эти правила могут идти от поставщиков кода разного уровня... Вот если бы приняли стандарт именования конкретно, то не было бы разногласий. Хотя я уже давно не встречал написания кода в отличном формате от camelCase.

С именование методов в формате camelCase() я полностью согласен и поддерживанию. Логично же, что классы именуем с большой буквы, константы с маленькой, методы с маленькой. И, в принципе, можно отличить одно от другого просто по написанию.

Спасибо за внимание, надеюсь, что материал был полезен, хотя и является изложением мыслей о прочтенном PSR-1.

@mepihin
07.12.2020 18:16 UTC
Первоисточник

Комментарии

@m03r
07.12.2020 14:57 UTC
+1

Краткий пересказ статьи:


  1. Если очень хочется, то смешивать декларации (кстати, откуда в статье взялись "логические заключения кода"?) и выражения с побочными эффектами — можно
  2. Свойства — в camelCase

С нетерпением ждём обзора на PSR-12, Symfony Coding Standard (предвижу что-то в духе "всё годится, кроме yoda conditions").


А если серьёзно, то не хватает хотя бы готовых файлов стиля для PHP-CS-Fixer, phpcbf, возможно, для встроенных инспекций phpStorm, и т. п. Хотите свой стандарт — двигайте его!

@mepihin
07.12.2020 16:03 UTC
0
Я наоборот говорю, что смешивать нельзя. А вот настройку для PHPSTRORM сделал почти по всему стандарту
@SerafimArts
07.12.2020 19:55 UTC
0

1) Как связан PHP 7 и неймспейсы?
2) Почему Yii2 выбран как "эталон следования PSR", хотя тот же Yii::$app является типичным примером сайд-эффекта, как следствие, очевидно, сам фрейм не соблюдает PSR-1?


Ну и да, поля классов в snake_case используются для AR маппингов на поля БД и в DTO под какие-нибудь API. Почему обязательно в lowerCamelCase?


А с другой стороны, если уж заговорили про именование полей, то пропустили ещё измышления, "на тему":


  • Глобальные функции всегда в snake_case().
  • Неймспейсы всегда в Camel\Case\ClassName.
  • Переменные и аргументы всегда в $lowerCamelCase.

А перед унарными операторами пробелы надо ставить вообще (как это делается в Laravel)? А слешики перед глобальными функциями (для fqn оптимизаций)?


Ну, короче, если уж хотелось устроить холивар на тему "непонятного в PSR", то очень поверхностно получилось.

@mepihin
08.12.2020 09:00 UTC
0
PHP 5.2.X по PSR немного другие именования классов, по этому было сказано про PHP 7. Yii2 был приведен в качестве примера, а не эталона. Согласен с Вами, что для AR использование snake_case актуально, но для реализации не AR свойств, по моему мнению, не корректно. Именование namespace я бы рекомендовал оформлять так, как именуются папки проекта.
Поверхностно, да. Я хотел поговорить именно по прочитанному материалу, не отходя в дебри размышлений, хотя это стоило сделать. Учту в следующих материалах.
08.12.2020 09:07 UTC
0
PHP 5.2.X по PSR немного другие именования классов, по этому было сказано про PHP 7

Помимо 5.2 есть ещё 5.3, 5.4, 5.5 и 5.6.


Именование namespace я бы рекомендовал оформлять так, как именуются папки проекта.

А папки проекта как именовать? Так же как неймспейсы? :D

08.12.2020 11:42 UTC
0
Помимо 5.2 есть ещё 5.3, 5.4, 5.5 и 5.6

Тут есть рекомендация в PSR-1
Code written for 5.2.x and before SHOULD use the pseudo-namespacing convention of Vendor_ prefixes on class names

А папки проекта как именовать? Так же как неймспейсы?

На этот счет я отмечал в своей статье PHP Code Style Conventions