Pourquoi le code Wordpress est-il si «heureux de l'espace»?

22

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

Pour plus d'informations sur cette approche, voir: enlace

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 affiché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 du code plus difficile visuellement. (/ opinion)

Mon souhait n’est pas de débattre de la pertinence de ce style. Je souhaite simplement comprendre les raisons pour lesquelles pourquoi il s’agit du style recommandé. Même les commentateurs sur les normes de codage WP sont curieux:

LesréponsesàlaquestiondeMKSafisontessentiellementlessuivantes:

  1. Pourplusdelisibilité
  2. Statuquo("c'est comme ça")

Mon raisonnement pour demander est que, personnellement, je ne vois pas l'intérêt d'intégrer les normes de codage WP (concernant "l'utilisation de l'espace") dans nos projets exclusivement internes. Cependant, je suis curieux s'il me manque quelque chose.

Existe-t-il d'autres raisons, apparemment valables ou non, de suivre le style "Utilisation de l'espace" de Wordpress?

    
posée rinogo 08.01.2015 - 01:52
la source

2 réponses

12

Resoning

En ce qui concerne "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 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 autre histoire et
  • Le guide de style 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 doit suivre le guide de style, mais si vous arriver à formater le code adjacent correctement alors qu’il en soit, mais les correctifs qui ne font que formater le code, ou commet que seul le code de formatage est interdit. "

     

- @TomJNowell dans les commentaires

Alternatives

Vous feriez mieux de vous en tenir aux normes PSR (notamment: 2) ou à des éléments comme les normes Symfony (ou simplement votre posséder).

Augmentation des performances & Outils

Il n’est pas rentable d’avoir une norme de codage (à part la possibilité de la partager et la minorité qui la déteste, le reste la dictant) ou d’avoir 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 GitPHPHs> ) sur commit. L’avantage que vous gagnerez sera d’environ max à 5% de l’espace de fichier d’origine, ce qui est à peu près équivalent à ce que la compression / minification de la syntaxe HTML vous offre. Il existe outils Node.js minify disponibles via npm pour cela.

Ce que j’ai personnellement trouvé vraiment utile est le PHP Linter et le _PHP Mess Detector. J'ai incorporé les deux dans la la bibliothèque GitPHPHsss afin que je n'ai pas à penser à les exécuter.

    
réponse donnée kaiser 08.01.2015 - 03:45
la source
7

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 également relatif à la lisibilité.

Cela peut être déroutant puisque les normes elles-mêmes de WordPress ont Des exemples avec des parenthèses dans les commentaires qui n'ont pas d'espaces et le code lui-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. Les parenthèses doivent en épouser le contenu. En fait, la plupart des normes de codage pour d'autres langues l'écrivent comme: (1, 2, 3) , donc c'est un peu mystérieux. pourquoi WP le fait de cette façon.

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

Versionplusgrandeàcomparer: enlace

Je préfère celui de droite, surtout si vous regardez un code complet, mais c'est une préférence personnelle.

    
réponse donnée Wyck 08.01.2015 - 05:04
la source

Lire d'autres questions sur les étiquettes