На предыдущем уроке, посвященном Nettuts +, вы узнали о PSR ; однако в этой статье не подробно описан процесс интеграции этого стиля кодирования в ваши проекты. Давайте это исправим!
Примечание: эта статья предполагает, что вы читали PSR-Ха? и понять, к чему относится PSR. Начнем с первого стандарта: PSR-0.
PSR-0 — стандарт автозагрузки
Плагин PHPCS — самый полезный инструмент, который я использовал.
В прошлом мы включали файлы PHP одним из двух способов:
- Использование гигантского блока операторов включения в верхней части каждого файла.
- Составьте список всех включений в одном файле и включите этот файл в ваш проект.
У обоих этих подходов есть свои плюсы и минусы, но, я думаю, мы все можем согласиться с тем, что ни одно из них не является оптимальным или современным решением. PHP5 ввел концепцию автозагрузки файлов на основе имен их классов; Таким образом, PSR-0 стремится поддерживать согласованность имен файлов.
Пространства имен не имеют ничего общего с именами файлов или автозагрузкой; технически вы можете объявить разные пространства имен в одном и том же файле. Например, следующий код является абсолютно допустимым.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
<?php
namespace Nettuts;
Class Hello
{
public function __construct()
{
echo «Nettuts+»;
}
}
namespace Gabriel;
Class Hello
{
public function __construct()
{
echo «Gabriel»;
}
}
$h = new \Nettuts\Hello();
$h = new \Gabriel\Hello();
|
В этом одном файле есть два класса Hello , но они находятся в разных пространствах имен. Последние две строки этого кода создают экземпляры классов Hello() в их соответствующих пространствах имен. Первый выводит «Неттутс +», а второй — «Габриэль». Пространства имен позволяют вам различать два класса с одинаковыми именами, так же, как вы привыкли к папкам на рабочем столе. Стандарт PSR-0 просто использует преимущества пространств имен, облегчая автозагрузку ваших классов. Постоянно называя ваши файлы, вы можете создать функцию, которая автоматически находит нужные файлы.
Чтобы быть PSR-1-совместимым, вы также должны следовать PSR-0.
Обязательно прочитайте полный стандарт , но суммируйте:
- Каждый класс должен иметь пространство имен с именем проекта (или создателя).
- Символы подчеркивания в имени класса должны быть преобразованы в разделители каталогов.
- Файлы должны иметь расширение
.php.
Например, ссылка на класс:
|
1
|
\Nettuts\Database\SQL_Postgres
|
если следующий PSR-0, следует перевести на этот путь:
|
1
|
./Nettuts/Database/SQL/Postgres.php
|
Как мы можем реализовать эту функцию? Наиболее очевидным решением является использование Composer , который поставляется с PSR-0-совместимым автозагрузчиком. Если вы используете Composer в своих проектах ( и вам следует ), тогда выберите его автозагрузчик, а не пишите свой собственный.
Загрузчик, совместимый с PSR-0, позволяет указать базовый путь, сообщая загрузчику, какой каталог искать в первую очередь. Для начала создайте простой файл composer.json который содержит следующий JSON:
|
1
2
3
4
5
6
7
8
|
{
«autoload»: {
«psr-0»: {
«Nettuts»: «./»,
«Gmanricks»: «vendor/»
}
}
}
|
Этот JSON-файл сообщает Composer, что мы хотим использовать стандарт PSR-0 для автоматической Nettuts всех файлов Nettuts namespaced с текущим каталогом (корневой папкой) в качестве базового пути. Мы также хотим автоматически Gmanricks все классы с пространством имен Gmanricks относительно папки vendor (например, ./vendor/Gmanricks/ClassName ).
Теперь введите « composer install », чтобы сгенерировать классы автозагрузки, или « composer dump-autoload » для последующих изменений, чтобы восстановить классы автозагрузки. Кроме того, не забывайте требовать автозагрузчик где-то в начале вашего проекта.
|
1
2
3
|
<?php
require ‘vendor/autoload.php’;
|
Composer — ваш лучший вариант, но могут быть сценарии, когда вам нужен маленький простой автозагрузчик. PHP-FIG предоставляет пример автозагрузчика, который вы можете использовать:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
|
function __autoload($className)
{
$className = ltrim($className, ‘\\’);
$fileName = »;
$namespace = »;
if ($lastNsPos = strrpos($className, ‘\\’)) {
$namespace = substr($className, 0, $lastNsPos);
$className = substr($className, $lastNsPos + 1);
$fileName = str_replace(‘\\’, DIRECTORY_SEPARATOR, $namespace) .
}
$fileName .= str_replace(‘_’, DIRECTORY_SEPARATOR, $className) .
require $fileName;
}
|
Важно отметить, что этот загрузчик пытается загрузить все классы, используя стандарт PSR в текущем каталоге.
Теперь, когда мы успешно загружаем классы, давайте перейдем к следующему стандарту: базовому стандарту кодирования.
PSR-1 — базовый стандарт кодирования
PSR-1 определяет общие руководящие принципы кодирования, которые можно разделить на две части.
Соглашения об именах
Пространства имен позволяют различать два класса с одинаковыми именами.
Как и в случае с любым другим языком программирования, соблюдение соглашений об именах в конечном итоге облегчает чтение и поддержку вашего кода. Вот несколько правил для подражания:
- Имена классов используют PascalCase .
- Имена методов должны быть в camelCase .
- Константы требуют все заглавные буквы, разделяя каждое слово с подчеркиванием (например,
CONSTANT_VARIABLE).
Кодовые обозначения:
Это больше, чем соглашение об именах; также следуйте этим рекомендациям:
- Используйте только
<?phpили<?=В вашем коде. Не закрывайте PHP внутри класса. - Файлы должны либо объявлять символы, либо использовать их.
- Файлы должны быть в формате UTF-8 без спецификации для кода PHP
Большинство из них говорят сами за себя, но среднее соглашение немного сбивает с толку. По сути, он требует, чтобы любое объявление, будь то функции, классы и т. Д., Было разделено на свои собственные файлы. Это не только продвигает лучшие практики, такие как повторное использование и разделение кода, но и делает ваш код аккуратным и чистым.
Стоит отметить, что каждый стандарт PSR основан на предыдущем стандарте PSR. Таким образом, чтобы быть PSR-1-совместимым, вы также должны следовать PSR-0. Следуя этим двум стандартам, ваш код будет правильно размещен и автоматически загружен. Там действительно нет причин, чтобы не следовать за ними.
Да, некоторые разработчики жалуются на PSR и предпочитают следовать другим соглашениям, но, следуя этому стандарту, вы можете поделиться кодом со всеми, не беспокоясь о его согласованности. Сказав это, никто не заставляет вашу руку здесь. Это просто рекомендуемое руководство.
Следующий стандарт, PSR-2, углубляется в особенности того, как вы должны структурировать свой код.
PSR-2 — улучшенный стандарт кодирования
PSR-2 углубляется в особенности того, как вы должны структурировать свой код.
Далее мы подходим к одному стандарту, с которым PHP-разработчики сталкиваются больше всего; на самом деле, это причина, по которой я решил написать эту статью.
PSR-2 определяет множество правил, многие из которых перечислены ниже:
- Вместо табуляции следует использовать четыре пробела.
- Идеальная длина строки должна быть не более 80 символов, но для всех строк должно быть установлено мягкое ограничение в 120 символов.
- Под
namespaceдолжна быть одна пустая строка и объявления обuse. - Открывающая скобка метода или класса должна находиться на отдельной строке.
- Закрывающая фигурная скобка метода или класса должна идти сразу после тела.
- Все свойства и методы требуют уровня видимости.
- Ключевые слова ‘
abstract‘ / ‘final‘ должны появляться перед видимостью, а ‘static‘ — после. - За ключевыми словами структуры управления должен следовать один пробел.
- Открывающая скобка управляющего оператора должна отображаться в той же строке, что и оператор.
Не забудьте просмотреть всю спецификацию для полного обзора.
PSR-2 так же важен, как и PSR-1 (и PSR-0). Он призван сделать код легким для чтения и сопровождения. Но, как говорится, « дьявол кроется в деталях». Есть много деталей, которые нужно запомнить, что может быть сложно, если ваши привычки программирования отличаются от того, что определяет стандарт. К счастью, если вы на борту, есть инструменты, которые помогут вам придерживаться PSR-0, PSR-1 и PSR-2. Возможно, лучшим инструментом является плагин Sublime Text , PHPCS .
PHPCS — PHP Code Sniffer
Плагин PHPCS — самый полезный инструмент, который я использовал, когда речь идет о приведении кода в форму. Это позволяет вам не только гарантировать, что ваш код соответствует стандартам PSR, но также использовать PHP-линтер для проверки синтаксических ошибок. Это отличная экономия времени; вам больше не нужно беспокоиться о синтаксических ошибках при тестировании кода в браузере.
Установите пакет с помощью Sublime Package Control (он называется Phpcs) или, альтернативно, с помощью Git, используя следующие команды:
|
1
2
|
cd ~/Library/Application\ Support/Sublime\ Text\ 2/Packages/
git clone git://github.com/benmatselby/sublime-phpcs.git Phpcs
|
Это устанавливает плагин, но вам нужно несколько зависимостей, прежде чем вы сможете настроить PHPCS. Еще раз, самый простой способ установить их с помощью Composer. Перейдите в каталог по вашему выбору и создайте файл composer.json со следующим JSON:
|
1
2
3
4
5
6
7
8
|
{
«name»: «Nettuts PHPCS Demo»,
«require»: {
«squizlabs/php_codesniffer»: «*»,
«fabpot/php-cs-fixer»: «*»,
«phpmd/phpmd»: «*»
}
}
|
Это устанавливает три зависимости в текущей папке. Откройте окно терминала в месте установки и введите composer install , и он загрузит необходимые пакеты.
Теперь вы можете настроить плагин в Sublime Text. Перейдите к «Предпочтения»> «Настройки пакета»> «PHP Code Sniffer»> «Настройки — Пользователь».

Плагин должен знать, где находятся три зависимости, а также стандарт, которому мы хотим придерживаться нашего кода:
|
1
2
3
4
5
6
7
8
9
|
{
«phpcs_additional_args»: {
«—standard»: «PSR2»,
«-n»: «»
},
«phpcs_executable_path»: «DEPENDENCY_PATH/vendor/bin/phpcs»,
«phpmd_executable_path»: «DEPENDENCY_PATH/vendor/bin/phpmd»,
«php_cs_fixer_executable_path»: «DEPENDENCY_PATH/vendor/bin/php-cs-fixer»
}
|
Эти настройки информируют PHPCS о том, что мы хотим придерживаться стандарта PSR2 и предоставляем путь каждой зависимости. Не забудьте заменить DEPENDENCY_PATH вашим реальным путем.
Перезапустите Sublime, и анализатор кода просканирует ваш код при сохранении файлов PHP.

При щелчке правой кнопкой мыши в редакторе также будет отображено несколько новых параметров, таких как очистка меток ошибок и попытки исправить нестандартные проблемы. Однако, учитывая, что цель этой статьи — привыкнуть к стандарту, я предлагаю вручную исправить ваш код и избегать использования функции автоматического исправления.
Вывод
Стандарты PSR были созданы таким образом, чтобы код можно было легко использовать повторно от проекта к проекту, не жертвуя при этом согласованностью стиля кода. Поначалу они могут показаться ошеломляющими, но вы можете использовать идеи и инструменты из этой статьи, чтобы помочь вам осуществить переход.
Еще раз повторим: никто не заставляет вас менять способ кодирования в PHP. Это просто руководство, изначально предназначенное для взаимодействия фреймворка. Тем не менее, в Nettuts +, мы считаем, что это лучшая практика для подражания. Теперь решайтесь! Если у вас есть какие-либо вопросы, давайте послушаем их ниже!