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

El núcleo de WP, muchos complementos de WP y los propios estándares de codificación de WP utilizan una "aplicación generosa" del Spacepersonaje (no para sangría, sino "dentro" de parens y corchetes). Esto parece ser exclusivo de Wordpress: este estilo / filosofía no parece estar presente en otros proyectos similares, PHP u otros.

Para obtener más información sobre este enfoque, consulte: https://make.wordpress.org/core/handbook/coding-standards/php/#space-usage

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

Me refiero al espacio después de foreach, después del primero (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 tipeo y (opinión) hace que el código de análisis sea visualmente más difícil. (/ Opinion)

Mi deseo no es debatir si este estilo es o no 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:

ingrese la descripción de la imagen aquí

Las respuestas proporcionadas a la pregunta de MK Safi son esencialmente:

Por legibilidad
Status quo (también conocido como "Así son las cosas")

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 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?

coding-standards

— rinogo
fuente

Puede hacer lo que quiera en sus proyectos internos, siempre que sea coherente. Como nota al margen, utilizamos pestañas en lugar de espacios, por lo que podríamos requerir menos tipeo, no es que esto importe de ninguna manera si tiene un IDE moderno que hace todo el formato por usted y puede reformatearlo para diferentes estilos (por ejemplo, sublime con paquetes, PHPStorm, etc.)

— Tom J Nowell

Gracias por tu comentario, @TomJNowell! Creo que tal vez me comuniqué mal en mi "pregunta": pregunto menos sobre las pestañas / espacios para la sangría, y más sobre las reglas mencionadas en "Uso del espacio" en make.wordpress.org/core/handbook/coding-standards/php / ... . Lo siento, no estaba más claro!

— rinogo

Es más fácil de leer cuando no tiene resaltado de sintaxis. Al menos por eso estoy usando ese estilo en proyectos internos. Tengo que editar PHP a menudo en una consola simple con vi en una configuración mínima.

— fuxia

FWIW, MediaWiki tiene una convención de estilo muy similar , y en realidad es bastante estricta en su aplicación (al menos en el núcleo). Incluso tienen un script para agregar automáticamente espacios faltantes. Todo lo que puedo decir es que uno se acostumbra, después de un tiempo.

— Ilmari Karonen

@rinogo Lo sé, los comentarios a veces son solo comentarios, no respuestas :)

— Tom J Nowell

Respuestas:

Resonancia

Con respecto al "espacio en blanco" (no importa si las pestañas o los 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 esté contribuyendo 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 a granel 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 formatea el código adyacente correctamente entonces que así sea, pero los parches que solo formatean el código o confirman que solo el código de formato están prohibidos ".

^{- @TomJNowell en los comentarios}

Alternativas

Es mejor seguir los estándares de PSR (a saber: 2) o cosas como los estándares de Symfony (o solo los suyos).

Aumento de rendimiento y herramientas

No hay ganancia que obtenga 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 pestañas o espacios. En caso de que le preocupe el espacio en disco innecesario utilizado o los programas más lentos, aún puede comprimir su código (consulte el proyecto GitPHPHooks ) en la confirmación. El beneficio que obtendrá será de aproximadamente un máximo del 5% del espacio de archivo original, prácticamente igual a lo que le proporciona la compresión / minificación de sintaxis HTML. Hay herramientas de minificación de Node.js disponibles a través de npm para eso.

Lo que personalmente me pareció útil es el PHP Linter y el _PHP Mess Detector. Incorporé ambos a la Biblioteca GitPHPHooks para no tener que pensar o preocuparme por ejecutarlo.

— emperador
fuente

La guía de estilo no se ignora para Core, pero no se aplica de forma retroactiva en masa en el código anterior, 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 formatea el código adyacente correctamente, que así sea, pero los parches que solo formatean el código o confirman que solo el código de formato está prohibido

— Tom J Nowell

@TomJNowell Y, por lo tanto, hace que la guía de estilo sea inútil :) De todos modos, presente una edición y agréguela a la respuesta. Es información notable.

— kaiser

Creo que no estaba muy claro en mi pregunta: me refiero menos a las pestañas frente a los espacios, y más al "Uso del espacio" en make.wordpress.org/core/handbook/coding-standards/php/… . Editaré la pregunta para que sea más clara.

— rinogo

@rinogo Te acerté la primera vez, de ahí el primer párrafo. Por cierto, considero que esto también es más legible.

— Kaiser

Los espacios después de los puntos son normales, por ejemplo $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 de legibilidad.

Puede ser confuso ya que los estándares de WordPress tienen ejemplos con paréntesis en los comentarios que no tienen espacios y la base de código en sí misma es confusa con algunas partes que tienen espacios y otras no (ver 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 deben abarcar sus contenidos. 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.

ingrese la descripción de la imagen aquí

Versión más grande para comparar: http://i.imgur.com/nTEbV7v.jpg

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

— Wyck
fuente

¡gracias por tu respuesta! El .espaciado tiene sentido para mí, ya .que en realidad es solo un operador binario, como +o -. Sus pensamientos sobre paréntesis "abrazando" su contenido es exactamente por qué hice esta pregunta. Este comportamiento, junto con las reglas aún más extrañas como las de los corchetes (WP dice que use $foo['bar']y $foo[ $bar ]) son exactamente por qué hice esta pregunta. :)

— rinogo