Использование PSR (по сравнению со стандартами кодирования WordPress)

На данный момент я не знаю, сколько статей я написал о важности стандартов кодирования WordPress (достаточно, чтобы ссылаться на них здесь, здесь и здесь, я думаю, что что-то значит).

Но после выполнения достаточного количества проектов для клиентов и работы с разработчиками, которые намного умнее и знакомы с расширенными инструментами, чем я, я нахожусь в том месте, где я решаю начать использовать PSR в разработке WordPress WordPress.

О, драма, да?

Если серьезно. Для этого есть причины, и бывают случаи, когда я думаю, что стандарты кодирования WordPress следует использовать, но я быстро убеждаюсь в том, что при создании любого современного проекта на основе WordPress должны использоваться более современные инструменты PHP (которые я кратко упомяну позже).

Использование PSR в разработке WordPress

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

Но учитывая, что я так много говорил об одном и другом, я подумал, что стоит поделиться своим мнением о том, почему я решил сделать этот сдвиг сейчас, и его обоснование.

1 Паритет с сообществом PHP

За последний год или около того, а на самом деле только за последние несколько месяцев этого года, я стал более привычным к:

• более опытные друзья-разработчики, ориентированные на PHP, одобряют инструменты, которые ожидают принятия PSR,
• использование //@codingStandardsIgnoreStart и //@codingStandardsIgnoreEnd в моем коде,
• настраиваемые наборы правил для моих проектов на основе сред, в которых они развернуты,
• и более.

В конечном счете, речь идет о желании поддерживать паритет (или его часть) с большим PHP-сообществом в целом, а также писать читаемый, основанный на стандартах код поверх WordPress. И я также хотел бы использовать некоторые другие инструменты и более свежие версии существующих инструментов (о которых я расскажу позже в этом посте).

2 проблемы современной среды

На момент написания этого поста PHP CodeSniffer (который требуется для запуска стандартов кодирования WordPress) имеет версию 3.0.2. Однако существуют проблемы совместимости с PHPCS и стандартами кодирования WordPress. В частности :

В новой версии PHP CodeSniffer есть несколько приятных функций, но внесены критические изменения, которые означают, что стандарты кодирования WordPress несовместимы.

Чтобы было ясно (и из-за характера программного обеспечения), это вопрос времени, когда это будет исправлено. Но если вы работаете над кодовой базой и используете Composer и стандарты кодирования WordPress, вам нужно явно указать версию PHP CodeSniffer, а не самую последнюю версию на данный момент.

Кроме того, у меня возникали проблемы с клиентами, когда отказ от применения PSR при разработке WordPress приводил к странному поведению при развертывании кода. Возможно, можно было бы привести аргументы в пользу того, что им следует настроить среду, но если они работают над тем, чтобы самые современные инструменты были доступны людям, которые их используют, зачем регрессировать?

3 Совместимость с современными инструментами

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

Например, мы использовали GrumPHP в недавнем проекте, который поддерживает множество инструментов, но мы не могли использовать, скажем, PHPMD из-за отсутствия принятия PSR. Что касается меня:

• Я хочу постоянно повышать уровень своих навыков разработчика (и, в данном контексте, PHP-разработчика),
• отсутствие поддержки более современных инструментов ставит меня в тупик, которого в противном случае я бы не испытал,
• Я хочу продолжать работать с WordPress, но с более современным рабочим процессом.

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

Как насчет стандартов кодирования WordPress

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

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

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