Estándares básicos de codificación a través de PSR-1
Ayer, hablé brevemente sobre la justificación del uso de PSR en comparación con los estándares de codificación de WordPress y el cuándo y el por qué de ambos. Pero eso no significa que no esté libre de puntos de confusión, especialmente si recién estás comenzando con ellos, ¿verdad?
Con eso quiero decir: supongamos que ha estado trabajando con los estándares de codificación de WordPress durante años (porque puedo relacionarme) y ahora hay un conjunto completamente nuevo de reglas y pautas a seguir. Pero no es una simple cuestión de cambiar algunos espacios en blanco y cambiar el nombre de los archivos.
Hay otros puntos a seguir, y cada uno se describe en un número, literalmente (PSR-1, PSR-2, etc.), de cómo debería funcionar algo.
Entonces, cuando se trata solo de los estándares de codificación básicos como se describe en PSR-1, ¿cuáles son algunas áreas problemáticas que podemos encontrar como desarrolladores de WordPress?
Estándares básicos de codificación (y efectos secundarios)
No tengo planes de revisar cada uno de los documentos y repetir lo que ya podemos aprender simplemente leyéndolos, pero creo que hay algo que decir para tomar algo que muchos de nosotros hacemos o experimentamos y ver cómo esto podría cambiar dentro de el contexto de WordPress.
Tome los efectos secundarios del estándar de codificación básica (o PSR-1 ), por ejemplo:
Un archivo DEBERÍA declarar nuevos símbolos (clases, funciones, constantes, etc.) y no causar otros efectos secundarios, o DEBERÍA ejecutar lógica con efectos secundarios, pero NO DEBERÍA hacer ambas cosas.
La frase "efectos secundarios" significa la ejecución de lógica que no está directamente relacionada con la declaración de clases, funciones, constantes, etc., simplemente por incluir el archivo.
Personalmente, considero que la segunda frase es la clave para comprender y evitar los efectos secundarios en nuestro código tanto como sea posible. Es decir, cualquier cosa que hagan nuestras clases debe ser autosuficiente o ser cohesivo con algo que pueda haber sido inyectado de alguna manera.
De todos modos, encontrar un código que introduzca un efecto secundario y limpiarlo no debería ser demasiado difícil. De hecho, me usaré a mí mismo como ejemplo.
Mira este fragmento de código en particular :
Este código proviene directamente de Toggle Admin Notices. De acuerdo, es simple, y el repositorio muestra una nota de cómo cambiarlo. Sin embargo, demuestra el punto, ¿verdad?
¿Cual es la solución? Esto viene en forma de carga automática (que también se cubre en PSR-4 ). Entonces, ¿qué pasaría si tuviera que refactorizarlo para que siguiera correctamente a PSR-1? Entonces, una forma de refactorizarlo puede verse así :
¿Es este un gran ejemplo? Probablemente no. Pero hay más que solo incluir archivos. Incluir esos archivos es hacer que este único archivo presente una variedad de efectos secundarios.
Eso significa que este único archivo es responsable de hacer mucho más que solo esas cuatro líneas de código. Piense en ello como si incorporara todo lo que implementan otros archivos. Se vuelve más complejo en ese punto.
Entonces tome esa idea y muévala a un sistema mucho más grande y podrá ver cómo y por qué esto sería problemático.
Por supuesto, también hay formas alternativas. Y este es sólo un ejemplo. Autocrítico, también. El punto no es tanto mostrar una forma definitiva de hacer esto, sino comenzar a sembrar ideas sobre cómo diseñamos, planificamos, construimos e incorporamos clases.
¿Qué pasa con las vistas?
Cuando se trata de escribir complementos, soy partidario de tratar lo que los usuarios verán como vistas. Pero parece haber una trampa aquí: se considera una mala práctica incluir archivos, ya que presenta efectos secundarios.
Por lo tanto, no queremos generar lógica en nuestras clases, pero también queremos separar la presentación de la lógica comercial.
Qué vamos a hacer?
El giro… es que vamos a utilizar la programación orientada a objetos para hacerlo. Diseñaremos una clase que genere HTML utilizando una plantilla de PHP.
Esto ha sido cubierto en profundidad por otra persona, y recomiendo leer esa publicación en particular para tomar la idea de los efectos secundarios, evitándolos e incorporando prácticas sólidas tanto como sea posible.
…¿Y Activos y Archivos Relacionados?
Lo sé: la idea de alejarse de los efectos secundarios (y mucho menos identificarlos) puede ser extraña al principio, especialmente cuando piensas en ciertas cosas que hemos hecho durante tanto tiempo.
Y puede generar preguntas como: ¿Está mal incluir archivos JavaScript o archivos CSS? Eso es probablemente un tema para una publicación diferente. Recuerde, sin embargo, que hay funciones API básicas directamente relacionadas con eso, y pueden ser parte de una clase estrictamente responsable de hacerlo.
Si el propósito de una clase es hacer exactamente eso y solo eso y usa funciones API para hacerlo, entonces diría que probablemente esté bien.
Pero me estoy desviando de eso por ahora (y tal vez sea un tema para los comentarios o, de nuevo, otra publicación).
En su lugar, mantenga sus clases sencillas y con un propósito. Deben hacer lo que dice PSR-1 y evitar hacer cosas como "[declarar] nuevas clases, funciones, constantes, etc." y “[ejecutar] lógica con efectos secundarios".