Share
En esta serie, hemos estado profundizando en los Estándares de Codificación de WordPress con el fin de hacer correr la voz acerca de ellos, entenderlos y comenzar a aplicarlos prácticamente en nuestro trabajo diario..
Si acaba de unirse a la serie, hasta ahora hemos cubierto los siguientes temas:
En este artículo, continuaremos construyendo sobre el contenido del artículo anterior: Específicamente, veremos el estilo de las llaves, las expresiones regulares y los matices de trabajar con etiquetas PHP en el contexto de Creación de temas, complementos y aplicaciones de WordPress..
A lo largo de esta serie, uno de los problemas que hemos reiterado una y otra vez es que los estándares de codificación ayudan a hacer que el código sea más fácil de leer y mantener, y que en última instancia deberían hacer que parezca que un desarrollador ha escrito el código..
Pero una de las cosas de las que no hemos hablado mucho es por qué estilo importa Primero, sin embargo, esto plantea la pregunta: ¿cuál es la diferencia entre el estilo y las convenciones de codificación??
Honestamente, creo que algunos dirían que no hay diferencia, de hecho, dirían que son sinónimos. No necesariamente estoy de acuerdo. Personalmente, la forma en que siempre lo he visto es que los estándares de codificación definir El estilo del código que se está escribiendo. Los estándares de codificación son las convenciones por las que diseñamos nuestro código..
Entonces, dicho esto, resumamos nuestra conversación sobre las convenciones de codificación observando cómo los estándares de codificación de WordPress definen el uso de llaves.
En general, las reglas son simples:
Estos principios a menudo se demuestran mejor en el código. Los dos primeros son simples:
// Ejemplos condicionales de una sola línea if (condition1) do_work (); if (condition1) do_work (); else dont_do_work (); // Condicionales multilínea if (condition1) do_work (); do_more_work (); else dont_do_work (); serious_be_lazy (); // Bucles de una sola línea (true para do / while, while, for y foreach) while (condition1) dont_stop_believing (); // Bucles de una línea (true para do / while, while, for y foreach) while (condition1) dont_stop_believing (); hold_on_to_that_feeling ();
Nada terriblemente complicado, ¿verdad??
De hecho, puedes ver que usé métodos en los bloques de arriba. Que es lo que nos lleva a nuestro próximo principio: si tiene un cuerpo demasiado complicado en su condicional, probablemente ayudará a refactorizar el condicional para facilitar la lectura..
Echemos un vistazo a un ejemplo..
En este ejemplo, vamos a recorrer los metadatos del usuario actual y, si la clave meta del usuario actual tiene la subcadena de "destruir:", eliminaremos la clave meta del usuario.
Observe en este ejemplo que todo este trabajo se está realizando en forma condicional, en una para cada bucle, y luego en otro condicional.
// Si la condición1 es verdadera ... si (condición1) // ... entonces obtenga los metadatos del usuario para el usuario actual foreach (get_user_meta (wp_get_current_user () -> ID) como $ meta_key => $ meta_value) // Si el usuario tiene un conjunto de valores de destruir, eliminarlo. Esto significa que optaron por no eliminar un usuario. if (strstr ($ meta_key, 'destroy:')) delete_user_meta (wp_get_current_user () -> ID, $ meta_key);
Un montón de código anidado, a la derecha?
Hay una variedad de formas en que esto puede ser refactorizado. De hecho, algunos desarrolladores irán tan lejos como para tomar cada bloque y abstraerlo en su propio método; tampoco hay nada de malo en eso..
Pero para demostrar este punto, solo proporcionaremos un nivel de abstracción: vamos a tomar el bucle y el condicional interno, lo moveremos a una función que acepte un usuario y luego realizaremos la acción original..
// Si condición1 es verdadera ... si (condición1) proceso_usuario (wp_get_current_user ()); function process_user ($ user) // Obtenga los datos de meteta del usuario para el usuario actual foreach (get_user_meta ($ user-> ID) como $ meta_key => $ meta_value) // Si el usuario tiene un conjunto de valores de destrucción, elimínelo . Esto significa que optaron por no eliminar un usuario. if (strstr ($ meta_key, 'destroy:')) delete_user_meta ($ user-> ID, $ meta_key);
Como dije, este es un ejemplo relativamente simple, pero el punto permanece: mover un bloque grande de un código a su propia función especializada puede recorrer un largo camino para refactorizar el condicional para que sea más fácil de leer..
En este punto, vamos a cambiar de marcha un poco y hablar brevemente sobre expresiones regulares. Si no está familiarizado con las expresiones regulares, simplemente sepa que son formas poderosas de realizar la comparación de caracteres o cadenas. Puedes leer mucho más sobre ellos en Wikipedia..
En algún momento durante su carrera de desarrollo de WordPress, es probable que los encuentre, ya sea en el código fuente principal, el código del tema o el complemento, o incluso que los necesite para realizar una acción en su propio proyecto..
Afortunadamente, PHP ofrece algunas funciones realmente simples y realmente poderosas para usar expresiones regulares en su código; sin embargo, hay usos apropiados e impropios de ellos cuando se trata de trabajar con ellos en WordPress.
Aquí están las reglas generales:
Accentsconagua
pregonar funciones que ofrece PHP\mi interruptor que ofrece PHP - use preg_replace_callback en lugar.Para aquellos que son curiosos, hay una serie de funciones que están disponibles.
Por ejemplo, recomiendo familiarizarse con:
preg_replacepreg_matchpreg_match_allFinalmente, preg_replace_callback es una forma de llamar a una función cuando una expresión regular ha encontrado una coincidencia.
Obviamente, las reglas para las expresiones regulares en WordPress son simples: es más bien una cuestión de conocer las funciones que usted utiliza. debería uso y lo que no debe usar, y cómo emplearlos en su trabajo diario.
Lo último que se debe cubrir en este artículo es la importancia de cómo usar las etiquetas PHP en los archivos PHP que conforman su proyecto. Afortunadamente, hay una regla de oro muy simple para esta situación en particular:
En primer lugar, esto significa que nunca debe abrir un archivo o una declaración de PHP en línea con o con . Naturalmente, todas las declaraciones de PHP en línea aún deben terminarse con el ?> etiqueta de cierre.
Ahora, este siguiente tema es un poco como una desviación de los Estándares de codificación, al menos en el momento de escribir esto, se está convirtiendo en una práctica más común para dejar la etiqueta de terminación fuera de la parte inferior del archivo si y solo si La primera línea del archivo en cuestión es una apertura. etiqueta.
Específicamente, esto es más común en el contexto de los complementos que en los temas y aquí se explica por qué: PHP es una forma en la que el código del lado del servidor se puede incrustar en el marcado de front-end. Como tal, requiere tanto una etiqueta de apertura como una etiqueta de cierre para que el intérprete sepa cómo analizar el código.
Pero si está escribiendo un complemento o un archivo de aplicación que es 100% PHP, entonces no hay necesidad de agregar una etiqueta de terminación al final del archivo. El analizador podrá detectarlo por sí mismo, y si hacer Incluya una etiqueta de terminación, entonces, potencialmente, puede dejar espacios en blanco al final del archivo que pueden causar todo tipo de problemas cuando llegue el momento de activar el complemento..
Entonces, además del estándar de codificación definido anteriormente, también agregaría:
A medida que nos acercamos al tramo final del examen de los Estándares de Codificación de WordPress, comenzaremos a enfocarnos en cosas más pequeñas como los operadores ternarios y las condiciones de Yoda; sin embargo, también analizaremos los puntos más finos de realizar consultas de SQL en línea y las reglas importantes en torno a eso.
Si aún no se ha puesto al día en la serie, ahora es un buen momento para leer lo que hemos cubierto hasta el momento en que se analizará hacia dónde nos dirigimos con el siguiente conjunto de artículos..
