Usando PHP CodeSniffer con WordPress Entendiendo los olores de código

A menudo, la forma en que escribimos el código depende de cómo empezamos con la programación.

Por ejemplo, si alguien tiene una educación formal en computación, es probable que conozca una variedad de principios que evitarán que escriban códigos de baja calidad. Esto no es una regla, por supuesto, sino una observación.. 

De manera similar, aquellos que se involucran en la programación por su cuenta, fuera de un entorno formal, a menudo terminan enseñándose a sí mismos y aprendiendo de una variedad de recursos diferentes. A veces, esto puede causar problemas con el tipo de código que se escribe.

Para ser absolutamente claro: no estoy diciendo que una educación formal en computación triunfe sobre alguien que se enseña a sí misma, y ​​viceversa. Algunos programadores fantásticos son aquellos que son educados; Otros son los que son autodidactas. Pero lo único que ambos tienen en común es que no están exentos de escribir olores de código de vez en cuando.

En este artículo, vamos a echar un vistazo introductorio a los olores de código. Vamos a examinar qué son, cómo se ven y cómo se manifiestan a menudo en el trabajo que hacemos. Usaremos PHP para nuestros ejemplos..

En la segunda parte de esta serie, vamos a echar un vistazo a cómo podemos evitar escribir olores de código. Específicamente, usaremos PHP, un par de herramientas y WordPress como el entorno de elección..

Pero primero, vamos a tener una introducción al código de olores..

¿Qué son los olores de código?

Dependiendo del tipo de desarrollador que solicites, es probable que obtengas una variación en la siguiente definición:

El olor a código, también conocido como mal olor, en el código de programación de computadoras, se refiere a cualquier síntoma en el código fuente de un programa que posiblemente indique un problema más profundo. 

Esta definición es directamente de Wikipedia. No está mal, pero no es mi opinión favorita sobre el tema. En cambio, mi definición favorita proviene de un programador prolífico y popular llamado Martin Fowler. Puede leer su versión completa sobre el tema del código de olores en este artículo, pero lo he resumido en los siguientes puntos:

1. "Un método largo es un buen ejemplo de esto: solo mirar el código y mi nariz se contrae si veo más de una docena de líneas de Java".
2. "Los olores no son intrínsecamente malos por sí solos, a menudo son un indicador de un problema más que el problema en sí".
   
3. "Las clases de datos (clases con todos los datos y sin comportamiento) son buenos ejemplos".
   

Si no has leído el artículo, él termina con esto:

Una de las cosas buenas de los olores es que es fácil para las personas sin experiencia detectarlos, incluso si no saben lo suficiente para evaluar si existe un problema real o para corregirlos.. 

Y creo que es una afirmación fantástica porque significa que este tema está perfectamente ubicado para aquellos que son programadores, pero no están seguros de dónde comenzar cuando se trata de identificar y abordar los olores de código..

En resumen, la experiencia no juega un papel importante en esto. Claro, aquellos que tienen más experiencia probablemente identifiquen olores más fácilmente (porque han visto más de ellos), pero los desarrolladores con menos experiencia deberían poder identificarlos.

Tienes ejemplos?

Por supuesto, cuando se trata de un tema como el código de los olores, a menudo es más fácil hablar de ellos en un nivel abstracto que realmente es hacer algo al respecto. Pero eso no es práctico, ni es aplicable a nuestro trabajo diario..

Dicho esto, ¿por qué no echar un vistazo a algún ejemplo de olores de código? Examinaremos por qué son problemáticos y luego ofreceremos una solución para eliminar el olor refactorizando el código..

Ejemplo 1: Convenciones de nomenclatura claras

Uno de los olores de código más fáciles de detectar es cuando un programador ha optado por usar nombres de variables poco claros. Es decir, en el contexto del código, no está claro qué se supone que representa una variable dada.

Claro, hay momentos en que esto es aceptable (como usar un yo en un para lazo). Pero en un método más largo, no es exactamente lo mismo que para lazo). 

Por ejemplo:

Si se nos da suficiente tiempo, probablemente podremos averiguar qué está haciendo esto. Primero, es un método relativamente simple. En segundo lugar, podríamos leer las variables, los bloques y regreso Valor para tener una mejor idea de lo que está sucediendo..
Pero si estamos buscando escribir código limpio que sea más fácil de entender al referirnos a él u otro programador trabaja con él, entonces usar convenciones de nomenclatura claras siempre ayuda. Y el código anterior no usa convenciones de nombres claras.
En su lugar, vamos a refactorizarlo para que se vea así:
Mucho más fácil de entender, ¿no es así??
Observe que el algoritmo en sí no ha cambiado, pero sí el nombre de la función y los nombres de las variables. Esto ha hecho ese Hay mucha diferencia en la lectura de este código. Si se nos pregunta qué se supone que debe hacer este código, podemos decir fácilmente algo como:
Devuelve una matriz de elementos marcados como verdaderos de una matriz predefinida de elementos.
En la medida de lo posible, evite usar nombres de variables genéricos y use la opción más clara para usted y sus compañeros.
Ejemplo 2: Mantente seco
En la programación, sería difícil encontrar un desarrollador que no haya oído hablar de KISS o DRY (ya sabe, "no se repita"). A pesar de esto, a menudo hacer repetirnos. 
Esto es indicativo del hecho de que el intento de adherirse a los principios DRY aterriza de manera diferente con diferentes tipos de programadores. ¡Y eso está bien! No hay una manera única de demostrar cómo cumplir con este principio..
Pero como hay varias formas de hacerlo, podemos proporcionar un ejemplo de cómo debería ser y cómo debería ser..
Supongamos que, a los fines del siguiente ejemplo, tenemos una función llamada save_post y acepta dos argumentos: una ID de publicación y una cadena que representa el título de la publicación. Un olor a código se vería algo así:
Pero ¿por qué podríamos escribir manualmente una llamada a save_post ¿tres veces? En su lugar, vamos a configurar una matriz asociativa, iterar a través de ella, y luego llamar al método una vez por iteración.
 '¡Hola mundo!', 2 => '¡Adiós mundo!', 3 => '¿Qué es este nuevo mundo?',]; foreach ($ post as $ post_id => $ post_title) save_post ($ post_id, $ post_title); 
Aunque llamar el método una vez es bueno, el método podría ser aún más flexible si acepta el conjunto de publicaciones como un argumento y deja el para cada bucle intacto, aunque ese no es realmente el punto de este ejemplo.
Si te encuentras haciendo el mismo método varias veces en una función pero con diferentes parámetros, puedes tener un olor de código. Y si lo hace, busque formas de refactorizarlo para que solo llame al método una vez.. 
Después de todo, no quieres repetirte..
Ejemplo 3: listas largas de parámetros
Una de las cosas más comunes que seguimos viendo en la programación, independientemente del idioma, es cuando una función acepta una gran cantidad de parámetros.. 
Los diferentes programadores tendrán opiniones sobre cuál es el número ideal de parámetros que una función debería aceptar, pero tiendo a pensar que tres (dar o tomar dos, tal vez) es un buen número.
Primero, veamos cómo se vería una función con una larga lista de parámetros. Es probable que no haya sorpresas en el siguiente código, y es posible que esté lidiando con algo exactamente como esto en uno de sus proyectos actuales:
Observe en el ejemplo anterior que no nos preocupa la implementación de la función. En cambio, nos preocupa la cantidad de parámetros que requiere. Esa es una gran cantidad de información para enviar, y hará que el método llame. ese mucho mas feo tambien.
Ni siquiera toca el tema de verificación y validación. Pero me divago en eso.
¿Cómo se puede limpiar este? Personalmente, soy un fanático de la creación de clases para representar colecciones de información como esta. Para este ejemplo en particular, podríamos tener una clase que presente la información de contacto de una persona. Además, esa persona podría estar asociada con un número de tarjeta de crédito.. 
Los detalles de esto podrían imponerse utilizando la lógica de negocios en otra parte de la aplicación, pero la abstracción se vería así:
Esta refactorización, aunque pequeña, es la más grande que hemos hecho en este artículo en particular. Tenga en cuenta que hemos hecho las siguientes cosas:
 
Creo un Información del contacto Clase que nos permite crear una instancia de un objeto que incluye toda la información de pago de una persona..
 
Creo un Información del pago Clase que nos permite mantener el número de tarjeta de crédito o débito para una persona, así como otros detalles asociados con ese método de pago..
 
Creado un Orden clase, colocado el orden de envio función dentro de ella, renombrado para enviar (ya que orden de envio sería redundante), y redujo su lista de parámetros a dos valores: una instancia de Información del contacto clase y la Información del pago clase).
 
Para ser claro, este ejemplo no maneja la verificación de asociación entre la información de contacto y la información de pago, ni muestra otras clases que pueden ser necesarias (como si el pago no se realizó en la transacción).
Pero ese no es el punto del ejercicio..
En cambio, estamos viendo el olor del código de las largas listas de parámetros y cómo podemos disminuirlos utilizando métodos prácticos y más mantenibles disponibles para nosotros..
Cuando esté escribiendo una función o haciendo una llamada a una función que requiera una gran cantidad de argumentos, busque formas de refactorizar esa función. Hará aumentar la cohesión del código y disminuir el olor..
Conclusión
Recuerde, los ejemplos que hemos visto anteriormente son solo eso. La lista de ninguna manera está completa, pero son olores comunes que probablemente veas en el código con el que trabajas o incluso en el código que escribes. Seré el primero en admitir que soy culpable de esto..
Además, hay muchos recursos disponibles para identificar y corregir los olores de código. Por suerte, también contamos con una serie de herramientas que nos ayudarán a descubrirlas automáticamente y a limpiarlas..
Y hacia donde nos dirigimos a continuación. Específicamente, vamos a usar PHP CodeSniffer para ayudarnos a evitar los olores del código en nuestro código. Luego, veremos cómo incorporar las reglas de WordPress en PHP CodeSniffer y conectarlo a nuestro IDE de elección..
Como se mencionó anteriormente en este artículo, el próximo artículo de la serie se centrará más en los olores de código al escribir código para WordPress. Revisaremos algunas herramientas y recursos disponibles para asegurarnos de que evitamos los olores del código y para asegurarnos de que estamos escribiendo un código más sólido.
Mientras tanto, estudie los ejemplos anteriores y consulte los recursos que he proporcionado, ya que son excelentes lugares para aprender más sobre olores y refactorización de códigos de personas y lugares que son notables dentro de nuestra industria.
Recuerde, puede ver todos mis cursos y tutoriales en mi página de perfil, y puede seguirme en mi blog y / o Twitter en @tommcfarlin, donde hablo sobre varias prácticas de desarrollo de software y cómo podemos emplearlos en WordPress..
No dude en dejar sus preguntas o comentarios en el feed a continuación, y trataré de responder a cada una de ellas..



		
			
	   
	




Código