Normas de codificación para WordPress [Guía]

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

Si todo el mundo formatea su código de la misma manera, usa comentarios, el mismo estilo de documentación, etc., trabajar juntos se vuelve mucho más fácil, y la curva de aprendizaje de 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 el código base. WordPress no sigue un enfoque estricto orientado a objetos y no utiliza un patrón MVC. Los proyectos que siguen las pautas de OOP y MVC sin excepción (como Laravel) tienen consistencia y mejores prácticas “horneado en” debido a su estructura.

WordPress desafortunadamente está maduro para la codificación de espaguetis, también conocido como haciendo 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 el espíritu de codificación de WordPress y crear más productos compatibles con WordPress. mostrar a la comunidad que te importa y disputas código de alta calidad.

Más en Hongkiat.com:

• 10 peores pesadillas para los desarrolladores web
• 5 razones por las que CSS podría ser el idioma más difícil de todos
• 30 reacciones comunes que tienen los programadores 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, siempre se deben usar llaves, incluso si no son necesarias. El propósito de los estándares de codificación de WordPress no es decidir si estás en lo correcto o incorrecto, es decidir cómo se debe hacer en WordPress..

Los estándares no son para debate. El uso de los estándares no es el lugar para oponerse a un estilo de sangrado que no le gusta. Si hay algo en los estándares de codificación, hazlo de esa manera. Los desarrolladores de WordPress te querrán por eso! Dicho esto, si no está de acuerdo con algo allí, levante la voz y avise a la gente. Siempre es posible hacer las cosas mejor, pero solo debes cambiar tu estilo de codificación si las normas 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 constantemente incorrecto que algo que a veces es correcto y otras no. Siempre puede escribir un script para cambiar las cosas de una sola vez o leer su código al final..

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

Normas 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 contribuidor principal. Pasar por todo tomaría un tiempo, así que he resaltado algunos fragmentos de los cuatro idiomas que frecuentemente veo que las personas se equivocan.

PHP

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

Estilos de corsé

Los frenos iniciales deben colocarse siempre al final de las líneas. Las declaraciones relacionadas deben colocarse en la misma línea que la abrazadera 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 un fanático del código aplastado (tengo mala vista), por lo que este es un código que me gusta aplicar. Poner espacios despues comas, y en ambos lados de lógico, comparación, cuerda y Operadores de Asignación, después Si, elseif, para, para cada y cambiar declaraciones y así sucesivamente.

¡Es más fácil decir dónde no se deben agregar espacios! Las únicas veces que no debes agregar espacios es cuando encasillado o referenciar arrays.

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

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] = 'this'; $ final_array [$ key_1] = 'is'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'example';  devuelve $ final_array; 

Convenciones de nombres

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

• Nombres de variables debiera ser todo en minúsculas, palabras separadas con guiones bajos
• Nombres de clase debería usar palabras en mayúsculas separados por guiones bajos. Acrónimos debería ser todo mayúscula
• Constantes debiera ser todo en mayúsculas, Spearated por guiones bajos
• Nombres de archivos debiera ser todo en minúsculas, separared con guiones

Condiciones Yoda

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

if ('Daniel' === $ name) echo 'Escribe un artículo, lo harás'; 

HTML

HTML no tiene tantas reglas asociadas con él, podría llegar a muchas cosas para hacer las cosas más modulares. Solo hay cinco reglas que debes saber al escribir HTML:

1. Su código debe validarse contra el validador W3C.
2. Las etiquetas HTML de cierre automático deben tener exactamente un espacio antes de la barra diagonal (esto es algo que personalmente odio, pero es una especificación W3C, no solo un motivo para mascotas de WordPress)
3. Los atributos y las etiquetas deben estar en 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 estar entre comillas (escritura no es correcto)
5. La sangría debe lograrse usando pestañas y debe seguir una estructura lógica.

CSS

CSS es otro lenguaje escrito de manera holgada, por lo que también hay mucho trabajo por hacer aquí. Aun así, los estándares son bastante fáciles para los programadores..

Selectores

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

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

Orden de propiedad

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

La mayor causa de aleatoriedad es la “oh también necesito agregar un margen” y luego procediendo a añadirlo al fondo. 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, es mejor que ver un espacio antes del valor; a veces usando taquigrafía, a veces no; a veces usando unidades en valores 0, a veces no, etc..

El formato del valor es bastante complejo pero viene naturalmente con algo de practica. Eche un vistazo a la guía exacta del 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 cantidad considerable de Javascript, se aprendieron gradualmente, como una idea posterior a HTML, CSS y PHP. Cuando recién empiezas con un nuevo idioma, cometes muchos más errores y si esos errores no causan errores fatales, pueden estar arraigados en ti..

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

Punto y coma

Esta es la regla más simple, pero se pasa por alto con frecuencia. Nunca, nunca, omita un punto y coma solo porque su código funcionará sin él. Es solo 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 de alto nivel sin sangrado me molestó incluso antes de leer los estándares.

Rompiendo lineas

Al romper cadenas largas, siempre rompa la línea después de un operador, no dejes una variable colgando. Esto hace que sea obvio a primera vista que la línea está rota y que 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 de ella. Este se ve muy extraño a mis ojos, pero la separación que se agrega entre la condición y el cuerpo es muy visible..

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

iteración jQuery

Según las normas de iteración jQuery. (jQuery.each ()) Solo debe usarse en objetos jQuery. Deberías usar básico para, para / en, mientras Bucles en Javascript para iterar sobre otras colecciones..

Conclusión

Hay mucho que observar y realizar un seguimiento y no hay manera de que alguien pueda aplicar todo esto de una sola vez. Debe llevar su código lo más cerca posible de los estándares y trabajar para seguirlos exactamente.

en mi opinión La consistencia es la regla más importante.. Es mejor hacer constantemente algo incorrectamente que cambiar a mitad de camino. Esto es especialmente cierto con las prácticas de formateo, ya que no afectan la funcionalidad de su código y, en su mayor parte, - puede ser fácilmente cambiado por lotes más tarde.

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