Cuando se desarrolló WordPress, desde el principio, Matt Mullenweg, el programador jefe y pronto CEO de Automattic, la compañía detrás de WordPress, hizo cumplir una larga lista de reglas con respecto a la escritura de código que todos los contribuyentes principales deben cumplir. Esas reglas definen cómo debe aparecer el código. Aquí está la lista completa de estándares de código PHP:
https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/

código

Los estándares de codificación tienen una importancia inmensa en el desarrollo para WordPress y todos pueden implementarlos al desarrollar para WordPress. No importa si está escribiendo un complemento personalizado para el tema de su cliente o hijo.

Pero primero hablemos de los estándares de codificación. ¿Por qué deberíamos utilizar estándares? Básicamente, el código debería funcionar, ¿verdad? ¿Por qué a alguien debería importarle si solo hay un espacio entre las cláusulas de condición o si algún comentario de documentación debe comenzar con una letra mayúscula y terminar con un punto?

Los estándares de codificación son muy comunes en casi todos los marcos y sistemas. El código que está escrito con reglas bien definidas tiene enormes ventajas sobre el código que no lo está.

Es mucho más fácil de leer. Cuando el código es escrito por varios programadores, o por un solo programador durante un largo período de tiempo, se vuelve muy difícil de leer. Parece un libro sin editor escrito por varios autores. En algún momento, el método privado comenzará con el prefijo de subrayado y, a veces, no, en ocasiones las variables son Camel Cased y otras no. Los espacios no son consistentes y parece un desastre.

Además, el uso de estándares de código puede ayudar a mitigar errores. Por ejemplo, Matt, en su infinita sabiduría, declaró que la ‘condición de Yoda’ era obligatoria. Significa que en lugar de

Si ($ var === verdadero)

Deberías escribir

Si (verdadero === $ var)

¿Por qué debería importarle a alguien eso? A menos que, por supuesto, tenga TOC…. La respuesta es simple. El uso de la condición de Yoda evita la colocación accidental en la condición, cosa que puede volverlo loco.

El uso de estándares de código hace que su código parezca un código sólido y profesional. El código que pasa la prueba de estándares de código es un código de calidad.

Decirle a sus clientes oa su jefe que está escribiendo según los estándares del código de WordPress es algo que puede ayudarlo a obtener ese contrato o este aumento de salario. Pero hay una gran brecha entre decir que estás trabajando según los estándares y realmente trabajar según ellos.

Los estándares del código son básicamente una lista muy larga y es difícil recordarlos todos. ¿Entonces, Cómo lo hacemos? Además, ¿cómo permitimos que el administrador / cliente verifique que el código esté escrito según los estándares?

Es por eso que tenemos una herramienta de análisis de código PHP Static que nos permite escanear el código que escribimos y verificar que el código siga todas las reglas de los estándares.

Usar phpcs es bastante fácil en Linux o Windows. Primero, debe instalar phpcs a través de PEAR:

$ pear instalar PHP_CodeSniffer

Verifique la instalación por

$ phpcs -i

Deberías conseguir algo como eso:

Los estándares de codificación instalados son PHPCS, Squiz, PSR2, MySource, PEAR, Zend y PSR1

Esto le permite escanear el código PHP mediante varios estándares conocidos de PHP. Necesitamos agregar estándares de WordPress a la herramienta phpcs. Crearemos algún directorio (no temporal) y un clon del proyecto GitHub del diccionario phpcs WordPress:

$ cd c: wpcs

$ git clone -b master https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards.git wpcs

Después de eso, agregaremos el diccionario de WordPress a phpcs:

$ phpcs –config-set installed_paths c: ruta a wpcs

Si probamos php –I, veremos que el diccionario de WordPress está ahí:

$ phpcs -i
Los estándares de codificación instalados son PHPCS, Squiz, PSR2, MySource, PEAR, Zend, PSR1, WordPress, WordPress-VIP, WordPress-Core, WordPress-Docs y WordPress-Extra
Ejecutar phpcs es bastante fácil. Vaya al directorio de su código y escriba esto:

$ phpcs – estándar = WordPress ./**/*.php

¡Eso es! Recibirá un informe sobre los problemas de inmediato:

ARCHIVO: /var/www/html/github/wp-notice/tests/bootstrap.php
————————————————– ——————–
SE ENCONTRARON 6 ERRORES QUE AFECTAN A 5 LÍNEAS
————————————————– ——————–
2 | ERROR | [ ] Falta el comentario del documento de archivo
4 | ERROR | [x] La primera condición de una sentencia IF de varias líneas debe
| | sigue directamente el paréntesis de apertura
19 | ERROR | [ ] Falta el comentario del documento de función
19 | ERROR | [ ] El nombre de la función “_manually_load_plugin” no es válido;
| | solo los métodos privados deben tener el prefijo
| | guion bajo
21 | ERROR | [x] El archivo se incluye condicionalmente; utilizar “incluir”
| | en lugar de
22 | ERROR | [x] El archivo se incluye condicionalmente; utilizar “incluir”
| | en lugar de
————————————————– ——————–
PHPCBF PUEDE ARREGLAR AUTOMÁTICAMENTE LAS 3 VIOLACIONES DE SNIFF MARCADAS
————————————————– ——————–

Obtener informes de cero errores es en realidad el objetivo aquí. Imprimir este informe a clientes y gerentes puede mostrarles que usted escribe el código según los estándares y que su código tiene realmente más calidad que otro código.

Puede ejecutar phpcs automáticamente y usar otra herramienta para solucionar varios problemas automáticamente. Incluso puede combinar los estándares con su IDE para recibir una notificación de inmediato. Pero antes de todo esto, conocer los estándares y saber phpcs puede ponerlo a usted y a su código en un nivel de calidad diferente.