¿Por qué el código de Wordpress es tan "espacio-feliz"?

22

El núcleo de WP, muchos complementos de WP y los propios estándares de codificación de WP use una "aplicación generosa" del carácter Space (no para sangría, sino "adentro" de parens y corchetes). Esto parece ser exclusivo de Wordpress, este estilo / filosofía no parece estar presente en otros proyectos similares, PHP o de otro tipo.

Para obtener más información sobre este enfoque, consulte: enlace

Ejemplo: foreach ( (array) $foo as $bar ) { ...

Me refiero al espacio después de foreach, después del primer ( , y antes del ) final (y otros espacios similares que se muestran en "Uso del espacio" en el enlace de arriba).

Este estilo me parece innecesario, requiere más escritura y (opinión) hace que el código de análisis sea más difícil visualmente. (/ opinión)

Mi deseo es no debatir si este estilo es una buena idea. Más bien, simplemente quiero entender los motivos de por qué este es el estilo recomendado. Incluso los comentaristas sobre los estándares de codificación WP son curiosos:

LasrespuestasproporcionadasalapreguntadeMKSafisonesencialmente:

  1. Parafacilitarlalectura
  2. Statusquo(tambiénconocidocomo"Así es como es")

Mi razonamiento para preguntar es que personalmente no veo mucho valor en la adopción de los estándares de codificación WP (con respecto al "Uso del espacio") en nuestros proyectos solo internos. Sin embargo, tengo curiosidad por si me falta algo.

¿Hay alguna razón más allá de las dos mencionadas anteriormente, aparentemente válida o no, para seguir el estilo de "Uso del espacio" de WordPress?

    
pregunta rinogo 08.01.2015 - 01:52

2 respuestas

12

Resonando

Con respecto a "espacio en blanco" (no importa si hay pestañas o espacios): es simplemente una preferencia personal que se quedó con el proyecto.

Los estándares de codificación de WP son un desastre y pueden ignorarse, siempre y cuando no contribuyas al núcleo, que es

  • una historia diferente y
  • la guía de estilo también se ignora allí.
  

"[...]" no se aplica de forma retroactiva al por mayor en código antiguo, ya que hace que el historial de svn / git sea muy difícil de usar. La política oficial es que el nuevo código debe seguir la guía de estilo, pero si suceda que el formato del código adyacente sea correcto, que así sea, pero los parches que solo dan formato al código, o confirman que solo el código del formato están prohibidos ".

     

- @TomJNowell en los comentarios

Alternativas

Es mejor que te limites a los estándares PSR (a saber: 2) o cosas como los estándares de Symfony (o simplemente tu propio).

Incremento de rendimiento & Herramientas

No hay ganancias que obtengas al tener un estándar de codificación (aparte de tener uno para compartir y la minoría que lo odia, mientras que el resto lo dicta) o tener más o menos tabulaciones o espacios. En caso de que le preocupe el uso innecesario de espacio en disco o programas más lentos, aún puede comprimir su código (vea el proyecto GitPHPHooks ) en cometer. El beneficio que obtendrás será de alrededor del máx del 5% del espacio del archivo original, más o menos igual a lo que te ofrece la compresión / minificación de sintaxis HTML. Hay herramientas de reducción de Node.js disponibles a través de npm para eso.

Lo que personalmente me resultó útil es el PHP Linter y el _PHP Mess Detector. Incorporé ambas en la GitPHPHooks Library , por lo que no tengo que pensar o preocuparme por su funcionamiento.

    
respondido por el kaiser 08.01.2015 - 03:45
7

Los espacios después de los puntos son normales, como $baz . '-5' , este estilo se usa en muchos estándares de codificación para operadores ( y + z ).

Esto se hace para mejorar la legibilidad, por ejemplo, uno de estos es más legible que el otro.

$cow.$dog.$cat.$table.$chocolate.$puddle.$iterator.$stuctureone.$stucturetwo

$cow . $dog . $cat . $table . $chocolate . $puddle . $iterator . $stuctureone . $stucturetwo

Esto se vuelve aún más obvio cuando está rodeado de otro "código".

En cuanto a los espacios alrededor del paréntesis ( 1, 2, 3 ) , no tengo idea, supongo que el argumento también es legible.

Puede ser confuso ya que WordPress estándares ellos mismos tienen los ejemplos con paréntesis en comentarios que no tienen espacios y el código base en sí mismo se confunde con algunas partes que tienen espacios y otras no (vea la captura de pantalla a continuación) incluso dentro de la misma función.

La mayoría de los estándares de PHP en realidad hacen lo contrario: los paréntesis deberían incluir su contenido. De hecho, la mayoría de los estándares de codificación para otros idiomas lo escriben así: (1, 2, 3) , por lo que es un poco misterioso. por qué WP lo hace de esta manera.

Aquí hay un ejemplo para comparar desde una función de WordPress.

Versiónmásgrandeparacomparar: enlace

Prefiero el de la derecha, especialmente cuando veo una pantalla completa de código, pero es una preferencia personal.

    
respondido por el Wyck 08.01.2015 - 05:04

Lea otras preguntas en las etiquetas