Pourquoi le code Wordpress est-il si "spatial-heureux"?
Les WP core, de nombreux WP plugins et les les normes de codage WP elles-mêmes utilisent une "application généreuse" du Space caractère (pas pour l'indentation, mais "à l'intérieur" des parenthèses et des parenthèses). Cela semble être unique à Wordpress - ce style/cette philosophie ne semble pas être présent dans d’autres projets similaires, PHP ou autrement.
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 fais référence à l'espace après foreach, après le premier ( et avant le dernier ) (ainsi que d'autres espaces similaires indiqués dans "Utilisation de l'espace" sur le lien ci-dessus).
Ce style me semble inutile - cela nécessite plus de dactylographie et (opinion) rend l'analyse de code syntaxique plus difficile visuellement. (/ Opinion)
Mon désir est de ne pas discuter si ce style est une bonne idée. Au lieu de cela, je veux simplement comprendre les motifs de pourquoi c'est le style recommandé. Même les commentateurs sur les normes de codage WP sont curieux:
Les réponses apportées à la question de MK Safi sont essentiellement les suivantes:
- Pour la lisibilité
- Statu quo (aka "C'est comme ça")
Mon raisonnement pour poser cette question est que, personnellement, je ne vois pas grand intérêt à adopter les normes de codage WP (concernant "l'utilisation de l'espace") dans nos projets internes uniquement. Cependant, je suis curieux s'il me manque quelque chose.
Existe-t-il des raisons, autres que celles mentionnées ci-dessus, apparemment valables ou non, de suivre le style "Utilisation de l'espace" de Wordpress?
Resonant
Concernant "espace blanc" (peu importe qu'il s'agisse d'onglets ou d'espaces): il s'agit simplement d'une préférence personnelle qui reste liée au projet.
Les WP normes de codage imo sont un gâchis et peuvent être ignorés - tant que vous ne contribuez pas au noyau, ce qui est
- une autre histoire et
- guide de style y est également ignoré.
"[...] il n'est pas appliqué rétroactivement en bloc sur du code plus ancien, car cela rend l'historique de svn/git très difficile à utiliser. La politique officielle est que le nouveau code devrait suivre le guide de style, mais si vous formatez code adjacent correctement alors qu’il en soit ainsi, mais les correctifs qui ne font que formater le code, ou qui commettent que seul le code de formatage sont interdits. " _
- @TomJNowell dans les commentaires
Des alternatives
Vous feriez mieux de vous en tenir aux normes PSR (notamment: 2) ou à des éléments comme les normes Symfony (ou simplement les vôtres).
Augmentation de la performance et outils
Avoir une norme de codage ne vous rapporte aucun profit (mis à part en avoir une à partager et la minorité qui la déteste, le reste la dictant) ou en ayant plus ou moins de tabulations ou d'espaces. Si vous craignez de perdre de l'espace disque ou d'utiliser des programmes plus lents, vous pouvez toujours compresser votre code (voir le projet GitPHPHooks ) lors de la validation. L’avantage que vous obtiendrez sera d’environ max _ 5% de l’espace fichier d'origine, ce qui est à peu près équivalent à ce que vous offrent la compression/minification de la syntaxe HTML. Il existe des outils Node.js minify 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 de GitPHPHooks afin de ne pas avoir à penser à le faire fonctionner.
Les espaces après les points sont normaux, tels que $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".
En ce qui concerne les espaces autour des parenthèses ( 1, 2, 3 ) Je n'en ai aucune idée, je suppose que l'argument est aussi pour la lisibilité.
Cela peut être déroutant puisque les WordPress standards eux-mêmes ont des exemples avec des parenthèses dans les commentaires qui n'ont pas d'espaces et que le code lui-même confond 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 standards PHP font en fait le contraire d'un appel à .. les parenthèses doivent en épouser le contenu. En fait, la plupart des normes de codage pour d'autres langues l'écrivent comme suit: (1, 2, 3), il est donc un peu mystérieux de savoir pourquoi WP le fait de cette façon.
Voici un exemple à comparer à partir d’une fonction WordPress.
Version plus grande à comparer: http://i.imgur.com/nTEbV7v.jpg
Je préfère celui de droite surtout lorsque je regarde un écran de code complet, mais c'est une préférence personnelle.