Uso de los PSR (frente a los estándares de codificación de WordPress)

En este punto, no sé cuántos artículos he escrito sobre la importancia de los estándares de codificación de WordPress (suficientes para vincularlos aquí, aquí y aquí, supongo, que cuenta para algo).

Pero después de hacer suficientes proyectos para clientes y trabajar con desarrolladores que son mucho más inteligentes y están más familiarizados con las herramientas avanzadas que yo, estoy en un lugar donde estoy optando por comenzar a usar PSR en el desarrollo de WordPress.

Oh, el drama, ¿verdad?

Hablando en serio. Hay razones para esto, y hay momentos en los que creo que los estándares de codificación de WordPress aún deberían usarse, pero rápidamente me estoy convenciendo de que construir cualquier proyecto moderno sobre WordPress debería usar herramientas PHP más modernas (que mencionaré brevemente más adelante).

Uso de PSR en el desarrollo de WordPress

Publicaciones como esta a menudo dan lugar a algún debate o respuesta dramática dentro de WordPress que no es mi intención ni es algo que creo que es necesario. Para ser honesto, conozco un buen número de otros desarrolladores que han hecho esto hace mucho tiempo, hablaron de ello, avanzaron y continuaron teniendo éxito tanto en su negocio como en sus proyectos de pasatiempos.

Pero dado que he hablado tanto sobre uno versus el otro, pensé que valía la pena compartir mi opinión sobre por qué estoy optando por hacer este cambio ahora y la razón detrás de esto.

1 Paridad con la comunidad PHP

Durante el último año más o menos, y realmente solo en los últimos meses de este año, me he acostumbrado más a:

• amigos desarrolladores orientados a PHP más experimentados que respaldan herramientas que esperan que se adopten los PSR,
• el uso de //@codingStandardsIgnoreStart y //@codingStandardsIgnoreEnd en mi código,
• conjuntos de reglas personalizados para mis proyectos en función de los entornos en los que están implementados,
• y más.

En última instancia, se trata de querer mantener la paridad (o un poco) con la gran comunidad de PHP en general mientras se escribe código legible basado en estándares sobre WordPress. Y también me gustaría usar algunas otras herramientas y versiones más recientes de las herramientas existentes (que discutiré más adelante en esta publicación).

2 problemas con los entornos modernos

Al momento de escribir esta publicación, PHP CodeSniffer (que se requiere para ejecutar los estándares de codificación de WordPress) se encuentra en la versión 3.0.2. Sin embargo, existen problemas de compatibilidad con PHPCS y con los estándares de codificación de WordPress. Específicamente :

La nueva versión de PHP CodeSniffer tiene algunas características interesantes, pero introduce cambios importantes que significan que los estándares de codificación de WordPress no son compatibles.

Para ser claros (y debido a la naturaleza del software), es cuestión de tiempo antes de que se solucione. Pero si está trabajando en una base de código y está utilizando Composer y los estándares de codificación de WordPress, deberá configurar explícitamente la versión de PHP CodeSniffer en lugar de la versión más reciente actualmente.

Además, he experimentado problemas con clientes en los que no adoptar los PSR en el desarrollo de WordPress ha resultado en un comportamiento extraño al implementar el código. Tal vez se podría argumentar que deberían ajustar el entorno, pero si están trabajando para tener las herramientas más modernas disponibles para las personas que las usan, ¿por qué retroceder?

3 Compatibilidad con herramientas modernas

Finalmente, hay una serie de herramientas modernas que no he podido usar, y mucho menos aprender, debido a lo que es y lo que no es compatible con la naturaleza del control de versiones.

Por ejemplo, estábamos usando GrumPHP en un proyecto reciente que tiene soporte para una variedad de herramientas pero no pudimos usar, digamos, PHPMD debido a la falta de adopción de los PSR. En lo que a mí respecta:

• Quiero mejorar continuamente mis habilidades como desarrollador (y, en este contexto, como desarrollador de PHP),
• la falta de soporte para herramientas más modernas me pone en un patrón de espera que de otro modo no experimentaría,
• Quiero seguir trabajando con WordPress pero hacerlo con un flujo de trabajo más moderno

Y en este momento, no usar los PSR está creando una brecha entre lo que está haciendo el resto de la comunidad de PHP y lo que está haciendo WordPress. Así que me gustaría seguir adelante mientras sigo trabajando en proyectos además del software que todavía disfruto usando.

¿Qué pasa con los estándares de codificación de WordPress?

Entonces, ¿qué significa esto sobre los estándares de codificación de WordPress y las publicaciones anteriores? Nada en realidad. A mi modo de ver: los estándares de codificación de WordPress deben usarse cada vez que trabaje en WordPress Core o algo que vaya a estar estrechamente integrado en él.

Pero si está trabajando en algo que se asienta sobre WordPress o algo que usa WordPress como base y puede usar los PSR en el desarrollo de WordPress junto con herramientas que pueden ayudar a aumentar la calidad del código base que está construyendo.

Entonces, al menos por ahora, esa es la perspectiva que voy a adoptar. Estoy ansioso por ver cómo se desarrolla en los próximos meses. Y, en cuanto a todo lo demás que he compartido, compartiré los aspectos de hacer este cambio.