На предыдущем уроке, посвященном 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 +, мы считаем, что это лучшая практика для подражания. Теперь решайтесь! Если у вас есть какие-либо вопросы, давайте послушаем их ниже!