Codificación de estándares para WordPress [Guía]

La razón por la que tenemos estándares de codificación (no solo para WordPress) es crear un entorno familiar para los programadores que trabajan en un proyecto. WordPress en particular abarca una amplia variedad de productos. Desde el núcleo hasta los temas y complementos, hay mucho que ver, y mucho sobre lo que mezclar.

Si todos formatean sus códigos de la misma manera, utilizan comentarios, el mismo estilo de documentación, etc., trabajar juntos es mucho más fácil, y la curva de aprendizaje para unirse a un nuevo proyecto no será tan pronunciada.

La necesidad de cohesión en WordPress se magnifica por el estado en el que se encuentra la base de código. WordPress no sigue un enfoque estricto orientado a objetos y no usa un patrón MVC. Los proyectos que siguen las directrices de OOP y MVC sin excepción (como Laravel) tienen consistencia y mejores prácticas "integradas" debido a su estructura.

WordPress lamentablemente está maduro para la codificación de espagueti, también conocido como hacer lo que quieras . Las mejores prácticas son difíciles de aplicar simplemente porque los productos que emplean código incorrecto pueden funcionar igual de bien (en la superficie).

Al seguir los estándares de codificación de WordPress, puede aprender un poco sobre la filosofía de codificación de WordPress, crear más productos compatibles con WordPress. muestre a la comunidad que le importa y discute el código de alta calidad.

Más sobre Hongkiat.com:

• 10 peores pesadillas para desarrolladores web
• 5 razones por las que CSS podría ser el lenguaje más difícil de todos
• 30 programadores de reacciones comunes tienen cuando las cosas van mal

Algunas notas sobre los estándares

Los estándares no definen lo correcto y lo incorrecto. Puede estar en desacuerdo con una regla, por ejemplo, los frenos siempre deben usarse, incluso si no son necesarios. El propósito de los estándares de codificación de WordPress no es decidir si está en lo cierto o no, es decidir cómo se debe hacer en WordPress.

Los estándares no están en debate. El uso de los estándares no es el lugar para tomar una posición en contra de un estilo de sangría que no te gusta. Si algo está en los estándares de codificación, hágalo de esa manera. ¡Los desarrolladores de WordPress te amarán por eso! Dicho eso, si no estás de acuerdo con algo allí, levanta la voz y hazle saber a la gente. Siempre es posible hacer las cosas mejor, pero solo debe cambiar su estilo de codificación si los estándares lo permiten.

Consistencia sobre la retención anal . Si está en el último 10% de su proyecto y acaba de descubrir que ha estado usando la convención de nomenclatura incorrecta para las clases, no cambie a mitad de camino. En mi opinión personal, preferiría leer algo consistentemente incorrecto que algo que algunas veces es correcto y otras no. Siempre puede escribir una secuencia de comandos para cambiar las cosas de una vez o leer su código al final.

¡Seguir los estándares es difícil ! Colocar un aparato ortopédico en la misma línea que la función en lugar de una línea a continuación es bastante fácil, incluso si está acostumbrado a presionar enter antes. Sin embargo, cuando necesitas pensar en 100 pequeñas reglas, todo el proceso se vuelve propenso a errores. A pesar de mi postura firme sobre los siguientes estándares, soy tan culpable como cualquier otra persona de cometer errores. Al final del día, una sangría incorrecta no es un pecado irrevocable. Haz tu mejor esfuerzo para seguir todas las reglas, aprenderás todo a tiempo.

Estándares de codificación de WordPress

En este momento WordPress tiene cuatro guías, una para cada idioma principal utilizado: PHP, HTML, Javascript y CSS. Forman parte de un cuerpo de conocimiento más amplio, el Manual del Colaborador principal. Pasar por todo tomaría un tiempo, así que he resaltado algunos fragmentos de los cuatro idiomas que con frecuencia veo que las personas se equivocan.

PHP

PHP es el lenguaje principal de WordPress y es un lenguaje tipado bastante lo que lo hace maduro para la regulación.

Estilos de refuerzo

Las llaves iniciales deben colocarse siempre al final de las líneas. Los enunciados relacionados deben colocarse en la misma línea que el corsé de cierre anterior. Esto se demuestra mejor con un ejemplo de código:

 if (condición) {// Hacer algo} elseif (condición) {// Hacer algo} else {// Hacer algo} 

Uso generoso del espacio

No soy fanático del código aplastado (tengo mala vista), así que este es uno que me gusta particularmente hacer cumplir. Pon espacios después de las comas, y en ambos lados de los operadores lógicos, de comparación, de cadena y de asignación, después de las instrucciones if, elseif, for, foreach y switch, y así sucesivamente.

¡Es más fácil decir dónde no se deben agregar espacios! Las únicas veces que no debe agregar espacios es cuando encasilla o hace referencia a matrices .

Una excepción bastante confusa a la excepción son las matrices donde la clave de matriz es una variable, en este caso, use un espacio. Este ejemplo debería aclarar esto:

 function my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') {if (null == $ complete_array) {$ final_array = $ complete_array; } else {$ key_1 = (entero) $ key_1; $ final_array [0] = 'esto'; $ final_array [$ key_1] = 'es'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'example'; } return $ final_array; } 

Convenciones de nombres

Puede ser difícil acostumbrarse a esto, especialmente si proviene de diferentes entornos. En una palabra:

• Los nombres de las variables deben estar en minúsculas, las palabras separadas con guiones bajos
• Los nombres de clase deben usar palabras en mayúscula separadas por guiones bajos. Los acrónimos deben ser mayúsculas
• Las constantes deben ser mayúsculas, habladas con guiones bajos
• Los nombres de los archivos deben estar en minúsculas, separados por guiones

Condiciones de Yoda

Las condiciones de escritura al revés de lo que está acostumbrado evitarán los errores de análisis. Se ve un poco raro, pero es mejor código.

 if ('Daniel' === $ nombre) {echo 'Escribir artículo lo harás'; } 

HTML

HTML no tiene muchas reglas asociadas, podría hacer muchas cosas para modular las cosas. Solo hay cinco reglas que debe saber al escribir HTML:

1. Su código debe validar contra el validador W3C.
2. Las etiquetas HTML de cierre automático deben tener exactamente un espacio antes de la barra diagonal (esta es una que yo personalmente odio, pero es una especificación W3C, no solo una queja de WordPress)
3. Los atributos y las etiquetas deben ser minúsculas. La única excepción es cuando los valores de los atributos están destinados al consumo humano, en cuyo caso deben escribirse de forma natural.
4. Todos los atributos deben tener un valor y deben ser citados (escritura no es correcto)
5. La sangría debe lograrse usando pestañas y debe seguir la estructura lógica.

CSS

CSS es otro lenguaje poco tipado por lo que hay mucho trabajo por hacer aquí también. Aun así, los estándares son bastante fáciles para los codificadores.

Selectores

Los selectores deben ser tan calificados como sea necesario, ser humanamente legibles, ser minúsculos con palabras separadas por guiones, y los selectores de atributos deben usar comillas dobles. Aquí hay un ejemplo conciso:

 input [type = "text"], input [type = "password"], .name-field {background: # f1f1f1; } 

Orden de propiedad

Los estándares reconocen la necesidad de un espacio personal aquí ya que no prescriben un orden específico para las reglas de CSS. Lo que sí dicen es que debes seguir una estructura semántica que tenga sentido . Agrupe propiedades por sus relaciones o agrúpelas alfabéticamente, simplemente no las escriba al azar .

La causa más grande de aleatoriedad es el "oh también necesito agregar un margen" y luego procede a agregarlo al final. Tome los .3 segundos adicionales y agregue la regla en el lugar lógico.

• Monitor
• Posicionamiento
• Modelo de caja
• Colores y Tipografía
• Otro

 .profile-modal {display: block; posición: absoluta; izquierda: 100px; arriba: 90px; fondo: # ff9900; color: #fff; } 

Formato de valor

Este es un lugar donde particularmente odio ver inconsistencias. Si no sigue las pautas, eso es mejor que a veces ver un espacio antes del valor; a veces usando la taquigrafía, a veces no; a veces usando unidades en 0 valores, a veces no, etc.

El formato del valor es bastante complejo, pero se produce naturalmente con algo de práctica . Eche un vistazo a la guía exacta en el Codex para formatear sus valores.

Javascript

En mi experiencia, Javascript es más propenso a ir por todos lados. Si bien muchos desarrolladores conocen una gran cantidad de Javascript, se aprendió gradualmente, como una ocurrencia tardía de HTML, CSS y PHP. Cuando recién comienzas con un nuevo idioma, cometes muchos más errores y si esos errores no causan errores fatales, pueden arraigarse en ti.

En muchos casos, los estándares se refieren a un límite de línea o indican "si una línea no es demasiado larga". Esto se refiere a la Guía de estilo de jQuery que impone un límite de 100 caracteres en las líneas . La guía de WordPress se basa en la guía de jQuery, por lo que es una buena idea leerla también.

Semicolon

Esta es la regla más simple, pero es una que se pasa por alto con frecuencia. Nunca, nunca, omita un punto y coma solo porque su código funcionará sin él. Es simplemente descuidado.

Sangría

Las pestañas siempre deben usarse para sangrar. También debe sangrar el contenido de un cierre, incluso si el contenido de un archivo completo está contenido en uno. No estoy seguro de por qué, pero el cierre sin precedentes del nivel superior me molestó incluso antes de leer los estándares.

Rompiendo líneas

Al romper cuerdas largas, siempre rompa la línea después de un operador, no deje una variable colgando . Esto hace que sea obvio a primera vista que la línea está rota y no acaba de olvidar un punto y coma.

Además, si una condición es larga, divídala en varias líneas y agregue una pestaña adicional antes. Esto se ve muy raro para mis ojos, pero la separación que agrega entre la condición y el cuerpo es muy visible.

 if (firstCondition () && secondCondition () && thirdCondition ()) {var html = 'Esta línea consta de' + n + 'palabras, por lo que debe desglosarse después de' + 'a operator'; } 

jQuery Iteration

De acuerdo con los estándares, la iteración de jQuery (jQuery.each()) solo debe usarse en objetos jQuery. Debe usar los ciclos básicos for, for / in, while en Javascript para iterar sobre otras colecciones.

Conclusión

Hay mucho que notar y hacer un seguimiento, y no hay forma de que alguien pueda aplicar todo esto de una vez. Debe llevar su código lo más cerca posible de los estándares y trabajar en seguirlos exactamente.

En mi opinión, la consistencia es la regla más importante . Es mejor hacer algo de manera consistente de manera incorrecta que cambiar a mitad de camino. Esto es especialmente cierto con las prácticas de formateo, ya que estas no afectan la funcionalidad de su código y, en su mayor parte, se pueden cambiar fácilmente por lotes más adelante .

¿Odias un elemento de los estándares de codificación? ¿Crees que se debería agregar algo? Háganos saber en los comentarios!

Olvide VR y AR, la realidad mixta es el futuro

Muchos consumidores de tecnología se subieron de inmediato al carro que era Pokemon Go, ya que su tan esperado lanzamiento finalmente sucedió durante 2016. Esto fue bastante comprensible ya que el juego había popularizado las palabras "Realidad Virtual" y "Realidad Aumentada" para los consumidores ocasionales.20

(Consejos de tecnología y diseño)

Crea animaciones HTML5 fácilmente con HTML5Maker

¿Quieres atraer a los lectores, con contenido animado e interactivo ? Si bien esto solía ser el dominio de Flash, lo que genera mucho tiempo de carga y posibles problemas de compatibilidad, HTML5 se ha convertido rápidamente en el método dominante para crear contenido web animado e interactivo.Por supuesto, no todos tienen el tiempo o las habilidades para codificar contenido HTML5; si eres una de esas personas, tal vez HTML5Maker es algo que debes probar.HTM

(Consejos de tecnología y diseño)