Pourquoi le code Wordpress est-il si «agréable pour l'espace»?

Le noyau WP, de nombreux plugins WP et les normes de codage WP eux-mêmes utilisent une "application très généreuse" du Spacecaractère (pas pour le retrait, mais "à l'intérieur" des parenthèses et des crochets). Cela semble être unique à Wordpress - ce style / philosophie ne semble pas être présent dans d'autres projets similaires, PHP ou autre.

Pour plus d'informations sur cette approche, voir: https://make.wordpress.org/core/handbook/coding-standards/php/#space-usage

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

Je me réfère à l'espace après foreach, après le premier (et avant la finale )(et d'autres espaces similaires montrés dans "Space Usage" sur le lien ci-dessus).

Ce style me semble inutile - il nécessite plus de frappe et (opinion) rend l'analyse du code visuellement plus difficile. (/ Opinion)

Mon désir n'est pas de débattre si ce style est une bonne idée. Au contraire, je veux simplement comprendre les raisons pour lesquelles c'est le style recommandé. Même les commentateurs des normes de codage WP sont curieux:

entrez la description de l'image ici

Les réponses apportées à la question de MK Safi sont essentiellement:

Pour la lisibilité
Statu quo (alias «C'est comme ça»)

Mon raisonnement pour demander est que personnellement je ne vois pas beaucoup de valeur à l'adoption des normes de codage WP (concernant "l'utilisation de l'espace") dans nos projets internes uniquement. Cependant, je suis curieux de savoir s'il me manque quelque chose.

Y a-t-il des raisons au-delà des deux énumérées ci-dessus, ostensiblement valides ou non, pour suivre le style «d'utilisation de l'espace» de Wordpress?

coding-standards

— rinogo
source

Vous pouvez faire ce que vous aimez dans vos projets internes, tant que vous êtes cohérent. En guise de remarque, nous utilisons des tabulations plutôt que des espaces, donc nous avons sans doute besoin de moins de frappe, ce n'est pas important du tout si vous avez un IDE moderne qui fait tout le formatage pour vous et peut reformater en différents styles pour vous (par exemple sublime avec packages, PHPStorm, etc.)

— Tom J Nowell

Merci pour votre commentaire, @TomJNowell! Je pense que j'ai peut-être mal communiqué dans ma "question" - je demande moins sur les tabulations / espaces pour l'indentation, et plus sur les règles mentionnées sous "Utilisation de l'espace" sur make.wordpress.org/core/handbook/coding-standards/php /… . Désolé je n'étais pas plus clair!

— rinogo

Il est plus facile à lire lorsque vous n'avez pas de mise en évidence de la syntaxe. C'est au moins pourquoi j'utilise ce style dans des projets internes. Je dois souvent modifier PHP dans une console ordinaire avec vi dans une configuration minimale.

— fuxia

FWIW, MediaWiki a une convention de style très similaire , et est en fait assez stricte à l' application (au moins dans le noyau). Ils ont même un script pour ajouter automatiquement des espaces manquants. Tout ce que je peux dire, c'est que l'on s'y habitue, après un certain temps.

— Ilmari Karonen du

@rinogo Je sais, les commentaires ne sont parfois que des commentaires, pas des réponses :)

— Tom J Nowell

Réponses:

Resoning

En ce qui concerne les "espaces blancs" (que ce soit des tabulations ou des espaces): c'est simplement une préférence personnelle qui collait au projet.

Les normes de codage WP imo sont un gâchis et peuvent être ignorées - tant que vous ne contribuez pas au noyau, ce qui est

une histoire différente et
le guide de style y est également ignoré.

"[...] il n'est pas appliqué rétroactivement en vrac sur du code plus ancien car il rend l'historique svn / git très difficile à utiliser. La politique officielle est que le nouveau code doit suivre le guide de style, mais s'il vous arrive de formater correctement le code adjacent alors tant pis, mais les correctifs qui ne formatent que le code, ou les commettent que seul le code de format sont interdits. "

^{- @TomJNowell dans les commentaires}

Alternatives

Il vaut mieux s'en tenir aux normes PSR (à savoir: 2) ou à des trucs comme les normes Symfony (ou juste les vôtres).

Augmentation des performances et outils

Il n'y a aucun profit à avoir une norme de codage (à part en avoir une à partager et la minorité qui la déteste, tandis que le reste la dicte) ou à avoir plus ou moins de tabulations ou d'espaces. Dans le cas où vous vous inquiétez de l'espace disque inutile utilisé ou des programmes peut-être plus lents, vous pouvez toujours compresser votre code (voir le projet GitPHPHooks ) lors de la validation. L'avantage que vous obtiendrez sera d'environ 5% maximum de l'espace de fichier d'origine, à peu près égal à ce que la compression / minification de la syntaxe HTML vous donne. Il existe des outils de minification Node.js disponibles via npm pour cela.

Ce que j'ai personnellement trouvé vraiment utile, c'est le PHP Linter et le _PHP Mess Detector. J'ai incorporé les deux dans la bibliothèque GitPHPHooks, donc je n'ai pas à penser ou à m'en soucier.

— kaiser
source

Le guide de style n'est pas ignoré pour Core, mais il n'est pas appliqué rétroactivement en vrac sur du code plus ancien car il rend l'historique svn / git très difficile à utiliser. La politique officielle est que le nouveau code doit suivre le guide de style, mais s'il vous arrive de formater correctement le code adjacent, qu'il en soit ainsi, mais les correctifs qui ne formatent que le code ou commettent que seul le code de format sont interdits

— Tom J Nowell

@TomJNowell Et rend donc le guide de style inutile :) Quoi qu'il en soit, veuillez déposer une modification et l'ajouter à la réponse. C'est une information remarquable.

— kaiser

Je pense que je n'ai pas été très clair dans ma question - je me réfère moins aux onglets qu'aux espaces, et plus à "l'utilisation de l'espace" sur make.wordpress.org/core/handbook/coding-standards/php/… . Je vais modifier la question pour être plus clair.

— rinogo

@rinogo Je vous ai bien compris la première fois, d'où le premier paragraphe. Btw, je considère cela aussi plus lisible.

— kaiser

Les espaces après les points sont normaux, par exemple $baz . '-5', ce style est utilisé dans de nombreuses normes de codage pour les opérateurs ( y + z).

Ceci est fait pour améliorer la lisibilité, par exemple l'un d'eux est plus lisible que l'autre.

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

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

Cela devient encore plus évident lorsqu'il est entouré d'un autre "code".

Quant aux espaces autour des parenthèses, ( 1, 2, 3 )je n'en ai aucune idée, je suppose que l'argument est également pour la lisibilité.

Cela peut être déroutant car les normes WordPress elles-mêmes ont des exemples avec des parenthèses dans les commentaires qui n'ont pas d'espaces et la base de code elle-même est source de confusion avec certaines parties ayant des espaces et d'autres pas (voir capture d'écran ci-dessous) même dans la même fonction.

La plupart des normes PHP font en fait le contraire d'un appel à .. les parenthèses devraient étreindre leur contenu. En fait, la plupart des normes de codage pour d'autres langues l'écrivent comme (1, 2, 3)suit : c'est donc un peu mystérieux pourquoi WP le fait de cette façon.

Voici un exemple à comparer à partir d'une fonction WordPress.

entrez la description de l'image ici

Version plus grande à comparer: http://i.imgur.com/nTEbV7v.jpg

Je préfère celui de droite, surtout quand on regarde un plein écran de code, mais c'est une préférence personnelle.

— Wyck
source

Merci pour votre réponse! L' .espacement est logique pour moi, comme .c'est vraiment juste un opérateur binaire, tout comme +ou -. Vos pensées sur les parenthèses "étreignant" leur contenu est exactement la raison pour laquelle j'ai posé cette question. Ce comportement, ainsi que les règles encore plus étranges comme celles pour les crochets (WP dit d'utiliser $foo['bar']et $foo[ $bar ]) sont exactement la raison pour laquelle j'ai posé cette question. :)

— rinogo