Los estándares de codificación de WordPress el operador ternario y las condiciones de Yoda

En este punto de la serie, hemos cubierto mucho terreno. Hasta ahora, hemos discutido los siguientes temas:

  • Convenciones de nomenclatura y argumentos de función
  • El uso de comillas simples y dobles
  • Sangría, uso del espacio y espacios finales
  • Estilo de refuerzo, expresiones regulares y etiquetas PHP

Muchas cosas, verdad?

En este artículo en particular, pensé que lo tomaríamos un poco más fácil antes de saltar al tema final. Como tal, vamos a cubrir dos temas realmente simples (que a menudo se ignoran o son demasiado complicados).

Específicamente, vamos a hablar sobre el operador ternario y vamos a hablar sobre las condiciones de Yoda..


Una palabra sobre los condicionales de WordPress

Cuando se trata de escribir código basado en WordPress, los Estándares de Codificación dicen estrictamente que primero debemos apuntar a la legibilidad. Directamente desde el Codex:

En general, la legibilidad es más importante que la inteligencia o la brevedad..

Pero hay es Un poco de un matiz para esto. Algunos desarrolladores consideran que el operador ternario está un poco en desacuerdo con este principio en particular específicamente porque es otra forma de escribir un si / else declaración, y si el desarrollador no está familiarizado con escribir o leer el operador ternario, viola este principio.

Vamos a echar un vistazo a esto más en profundidad en un momento.


El operador ternario

Primero, para aquellos que no están familiarizados, el operador ternario es una forma simplificada de escribir un si / else sentencia condicional. Es típicamente usado solamente cuando el condicional es de la forma más simple y solamente cuando hay una sola Si y una sola más bloquear.

Por ejemplo, digamos que tenemos un condicional como este:

 $ uses_gasoline = null; if ('hybrid' == $ car_type) $ uses_gasoline = false;  else $ uses_gasoline = true;  echo $ uses_gasoline;

Claro, esto es un poco de un ejemplo artificial, pero entiendes el punto. Después de todo, simplemente estoy tratando de demostrar cómo convertir un condicional como este en una forma utilizada por el operador ternario.

Siguiendo con el ejemplo anterior, puedes hacer lo siguiente:

 $ uses_gasoline = 'hybrid' == $ car_type? falso verdadero; echo $ uses_gasoline;

¿Tener sentido? Una cosa importante a tener en cuenta: el operador ternario está probando la verdad (en lugar de la falsa, obviamente).

Por lo que vale la pena, esto me parece mucho a leer una oración. La primera cláusula es hacer una pregunta (obviamente marcada por un signo de interrogación), con las dos respuestas posibles basadas en la evaluación del condicional.

Ahí es Una advertencia para verificar si todo está documentado en el Codex:

Una excepción sería usar ! vacío(), Como probar falso aquí es generalmente más intuitivo..

En mi experiencia, ese ha sido el único momento para usar una evaluación negativa en el condicional. Todas las veces que he pasado trabajando con el operador ternario, he encontrado que las pruebas de falso a menudo hacen que la evaluación ternaria sea más difícil de descifrar.

Además, he descubierto que es mejor proporcionar una evaluación única y tal vez Dos evaluaciones bajo circunstancias muy simples y claras..

Aparte de eso, eso es cómo puede utilizar el operador ternario en su trabajo diario de WordPress


Condiciones Yoda

Si sigues de cerca, notarás que hice algo que la mayoría de los lenguajes de programación (o incluso las plataformas basadas en PHP fuera de WordPress) no hacen regularmente:

La comparación del condicional se realizó comparando el valor con la variable; no al revés.

Tradicionalmente, veríamos algo como esto:

 $ uses_gasoline = null; if ($ car_type == 'híbrido') $ uses_gasoline = falso;  else $ uses_gasoline = true;  echo $ uses_gasoline;

Y el operador ternario correspondiente se vería así:

 $ uses_gasoline = $ car_type == 'híbrido'? falso verdadero; echo $ uses_gasoline;

Así que si la mayoría de lenguajes de programación y plataformas no hacer usa las condiciones de Yoda, entonces por que hace WordPress?

Según el Códice:

En el ejemplo anterior, si omite un signo de igual (admítalo, esto sucede incluso para los más experimentados de nosotros), obtendrá un error de análisis, porque no puede asignar una constante como cierto. Si la declaración fuera al revés ($ the_force = true), La asignación sería perfectamente válida, volviendo. 1, causando que la sentencia if evalúe cierto, y usted podría estar persiguiendo ese error por un tiempo.

En mi opinión, esta es una muy, muy buena explicación para realizar comparaciones como esta. especialmente dentro de lenguajes dinámicamente escritos como PHP y JavaScript.

Independientemente de si está de acuerdo con este enfoque o no, es parte de la norma y tu son Voy a ver esto usado a través del núcleo de WordPress, temas, complementos, artículos y más.

Para ello, recomiendo encarecidamente comenzar a implementar en su propio trabajo..


Conclusión

Como mencioné al principio, este post en particular sería mucho más simple y directo que algunos de los otros materiales que hemos cubierto en la serie hasta ahora..

En este punto, solo tenemos un tema principal más que cubrir: Consultas de base de datos.

Después de eso, haremos una revisión de todos los temas que hemos descrito a lo largo de esta serie para resumir los principios que hemos detallado en las Normas de codificación..

Pero primero, en consultas de base de datos.