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

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.

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.