Créer son moteur de templates PHP, c’est possible

Si vous codez sur PHP depuis quelques temps, vous avez certainement déjà utilisé un moteur de templates. Mais était-il adapté à votre projet ? Je vous propose ici d’apprendre à créer le votre, toujours simplement.

Avant toute chose, je précise que cet article n’est qu’une piste, une ébauche pour créer un tel système. A la fin de celui-ci, vous aurez une version utilisable du mécanisme, mais en aucun cas il n’est une bonne pratique, pour les raisons que je détaillerai plus bas.
Et puis, je ne tiens pas à entrer dans une polémique trollesque du « Mais PHP est déjà un moteur de template ». Non, je l’ai assez entendu.

Un moteur de templates ?

Si vous ne connaissez pas, sachez que c’est un système qui permet de séparer le code PHP d’une page de son design. C’est à dire que dans votre vue, appelée template, il n’y aura que du HTML et des variables PHP déguisées.

PS : Rangez vos bâtons, ce que j’appelle design ici regroupe tout le code HTML, donc pas uniquement le design mais aussi l’UI, l’ergonomie, la structure, tout en fait.

Voilà à quoi un template peut ressembler :

Même si vous n’en utilisez pas, vous en connaissez sûrement :

Twig

twig

Twig est à l’heure actuelle le plus répandu des moteurs de templates PHP. Créé par SensioLabs, la boite qui supporte Symfony, celui-ci est devenu LA référence et le moteur de templates fournit par défaut avec le framework.

Smarty

smarty

Smarty est le plus vieux des moteurs de templates. Je n’ai pas la date de sortie de sa première version, mais sait que la 2.6 est sortie en.. 2003 ! Et oui, ça remonte déjà.. Comme Twig, il offre un large panel de fonctions, des filtres, gestion du cache etc

Quels sont les avantages ?

Aux premiers abords, j’aime dire qu’un moteur de templates rend la vue plus agréable à lire et à comprendre, mais aussi à maintenir. Vous avez le script d’un coté, le design de l’autre.
Qui plus est, pas de <?php echo $var; ?> partout, uniquement une syntaxe définie. Si vous bossez avec un web-designer qui est limite avec le PHP, il sera certainement le plus ravi de tous de l’utilisation d’un tel système.
Enfin, point non négligeable, les moteurs de templates intègrent généralement une gestion du cache, ce qui permet d’afficher une page sans avoir à la traiter à chaque fois.

Oui mais

Personnellement, j’adore les moteurs de templates, je ne travaille plus sans. Aussi je n’ai sûrement pas une vision très objective. Quoi qu’il en soit, il faut avouer que ces librairies font perdre légèrement en terme de performance (rien de sensible pour l’humain), et qu’elles augmentent plus ou moins le nombre de fichiers dans votre projet.
Mais c’est vraiment peu comparé au gain final 😉

Pourquoi créer le sien ?

Étant autodidacte dans l’âme depuis tout petit (je n’ai jamais suivi un seul cours d’informatique), j’aime créer mes propres scripts (Do It Yourself powa 😉 ), surtout parce que j’apprends de nouvelles pratiques et techniques à chaque fois.
Surtout, je considère que les moteurs de templates que j’ai évoqué plus haut sont trop lourds, trop complets et s’occupent de trop de choses : Si je dois convertir une date, c’est au controlleur de faire ça, pas à la vue, tout comme échapper du code, nettoyer des données, …

Bien sûr, il y a des fonctionnalités intéressantes, mais pour 95% des applications, je ne me sert que des variables et des boucles.

Entrons à présent dans le vif du sujet.

Cahier des charges

Pour cette démonstration, je souhaite mettre en place les choses essentielles à tout bon moteur de templates, c’est à dire :

  • Créer un template à partir d’un fichier
  • Lui assigner des variables
  • L’afficher

Coté template, je souhaite :

  • Pouvoir afficher des variables de tous types (string, array, objets)
  • Avoir un niveau de profondeur infini sur les variables, c’est à dire utiliser des tableaux multidimensionnels, des méthodes et attributs des objets
  • Utiliser des conditions simples
  • Faire des boucles
  • Commenter mon template

Point important, j’utiliserai pour mes templates la syntaxe de Twig. Pourquoi ? Car c’est une syntaxe connue, aussi je ne me perdrai pas lorsque j’écrirai mes templates, que je pourrai également utiliser avec Twig du coup, et surtout, les IDE proposent maintenant l’autocomplétion pour les templates Twig 🙂

Il me semble que ce sera déjà pas mal, non ? 😉

Comment ça fonctionne ?

Nous allons tout d’abord créer une classe Tpl.
Celle-ci devra accepter un nom de fichier, le template.
On pourra alors assigner des variables à notre objet.
Lorsque l’utilisateur voudra afficher le template, l’objet récupérera le contenu du fichier, le parsera afin de transformer notre syntaxe en code PHP compréhensible. Enfin, elle évaluera le code PHP.
On utilisera les fonctions de temporisation de sortie pour ne pas afficher en temps réel le code interprété.

Ça peut paraitre compliqué mais vous verrez qu’il n’y a rien de difficile là dedans si vous êtes un peu à l’aise avec les Regex.

J’ai la classe

Créons notre classe Tpl :

Celle-ci est vide pour le moment, mais ça ne va pas durer longtemps 😉

Les attributs

Voici les attributs nécessaires au bon fonctionnement de notre classe :

Les commentaires devraient être suffisants.
En revanche, j’ai volontairement mis les attributs en protected pour ne pas qu’ils soient publics, mais également parce que je souhaite que ma classe soit étendue. Vous comprendrez l’utilité plus tard.

Le constructeur

Le constructeur de la classe ne devra accepter qu’un argument : le chemin complet du fichier template.
On testera l’existence du fichier, et s’il n’existe pas, on lancera une nouvelle exception :

En revanche, si le fichier existe, on stocke le chemin du fichier dans l’attribut filepath.

Assigner des variables

Pour être utile, il faudra pouvoir assigner  des variables aux templates. Pour ce, on stockera toutes ces données dans l’attribut data :

Cette fonction très simple servira à ajouter des variables utilisables dans notre template. Ces variables peuvent être de tous types, exceptées les closures.

La fonction de sortie

Nous allons à présent écrire la fonction de sortie, celle qui sera appelée par le script lorsqu’on voudra récupérer le code parsé du template :

Le code est, comme d’habitude, assez simple et les commentaires indiquent assez bien ce que fait la méthode.

A l’appel de la méthode, on enclenche la temporisation de sortie afin de ne pas afficher le code qui sera lu.
On récupère ensuite le contenu du fichier template défini dans le constructeur, que l’on parsera.
Enfin, on fait un eval afin d’exécuter le contenu, avant de libérer le tampon que l’on retourne.

En revanche, vous pouvez constater que la fonction fait appel à d’autres méthodes que nous n’avons pas encore implémenté. Faisons cela de suite :

Récupérer le contenu

Nous allons écrire la fonction get_content(), qui ira récupérer le contenu du fichier template et le retournera :

Cette méthode est définie privée car nul besoin d’y accéder par le script. En revanche, on peut imaginer une autre classe qui étendrait notre classe Tpl et qui la surchargerait.

Parser : 1ère partie

Écrivons à présent la première partie de notre parser.
En premier lieu, nous ajouterons la possibilité d’utiliser une variable dans notre template, préalablement passée au template via la fonction set().
Dans notre template, une variable sera définie par cette syntaxe :

Chaque variable qui devra être affichée sera entourée de 2 accolades {{ variable }}. Nous prendrons en compte également le fait de pouvoir espacer ou pas les accolades du nom de la variable.

Cette fonction, qui sera constituée uniquement d’opérations de Regex, est chargée de parser le contenu. Ici, le preg_replace() va remplacer toutes les occurrences de {{ variable.child.name }} en <?php $this->_show_var('variable.child.name'); ?>

Lorsque le code compilé sera interprété, la méthode _show_var() sera donc appelée. Celle-ci ne devra assumer qu’une seule fonctionnalité : Afficher le contenu de la variable.

Afficher une variable

Vous verrez que cette méthode sera plus alambiquée qu’on ne pourrait le croire : A première vue, un echo $variable; serait suffisant. Mais n’oublions pas que nous souhaitons pouvoir afficher des tableaux à plusieurs dimensions, des attributs de méthodes etc :

Un simple echo en effet, suivi d’une nouvelle méthode, que nous allons implémenter tout de suite. Vous en comprendrez alors son usage.

Récupérer une variable

Je vous donne le code de la méthode, j’explique ensuite :

Cette méthode accepte 2 arguments : Le nom de la variable, et son parent. Etant donné que toutes les variables ont été assignées au template, chaque variable a pour parent l’attribut data de notre objet Tpl.
Mais dans chaque variable, chaque point déterminera que la partie située à sa droite est un enfant de la variable : {{variable.child1.child2.child3. ... }}. Ici, child2 est le parent de child3, child1 est le parent de child2, variable est le parent de child1. Enfin, variable a pour parent le fameux attribut data.

En premier lieu, la variable sera ‘explosée’, en utilisant le ‘.’ comme séparateur.
Si le nombre de pièces est égal à 1, cela signifie qu’il n’y a pas de ‘.’ et donc pas d’enfant. Donc le nom de la variable est celui à récupérer.

En revanche, si un ou plusieurs enfants sont trouvés :
On extrait la première pièce du tableau $parts. Celle-ci est le nom du parent. On va donc récupérer le parent grâce à la fonction getSubVar(), que nous verrons par la suite.
Ensuite, nous réunissions toutes les pièces de la variable afin de reconstituer la variable décomposée, puis on relance cette même méthode, en indiquant le nouveau nom de variable et le nouveau parent, récupéré 3 lignes plus haut.

Récupérer l’enfant

Cette méthode est chargée uniquement de récupérer un enfant du parent, c’est à dire un attribut d’un objet, un sous-tableau d’un tableau, etc :

Comme tout à l’heure, la méthode accepte 2 paramètres : le nom de la variable à récupérer, et son parent.
Le traitement n’est alors qu’une succession de tests pour déterminer le type du parent, de l’existence et du type de la variable.
Si celle-ci est trouvée, elle est retournée. Dans le cas contraire, on renvoie une chaine vide.

Premier test

A présent, notre classe est prête pour un essai.

Passons au code. J’ai créé une petite classe Article pour tester l’appel à une méthode :

Et voilà le script :

Rien de compliqué encore une fois, j’initie des variables, un tableau et 2 objets que je passe au template via la fonction set().

Enfin, nous allons créer un template, le fichier HTML qui recevra nos variables. J’ai appelé celui-ci index.tpl, mais vous pouvez lui donner l’extension que vous souhaitez :

En lançant le script, vous devriez voir le résultat à l’écran :
tpl1

C’est pas beau ?

Cet article s’arrête ici, je publierai la suite dans quelques jours dans un autre billet, histoire qu’il ne devienne pas encore plus long qu’il ne l’est déjà, afin de traiter les points suivants comme les boucles et les tests de condition.

Retrouvez le code complet de la classe sur ce Gist.

15 Commentaires

Ajouter un commentaire

  1. Très bonne introduction.
    Et mon mien, il te plaît mon mien ? 🙂 https ://github.com/figdice/figdice

    J’y mets en avant le principe de l’inversion de contrôle, selon lequel c’est la vue (le fichier de template) qui « tire » les données dont elle a besoin, via des fournisseurs de données que le contrôleur (le code PHP qui instancie la vue) sait construire à la demande grâce au pattern de Factory.

    A minima, une lecture intéressante, en particulier concernant le moteur d’évaluation d’expressions.

    Des avis ? 🙂

    • Bonjour Gabriel,

      J’étais déjà tombé sur FigDice, et j’avoue que c’est un système très complet.
      La particularité, comme tu le soulignes, est que la vue va récupérer les infos au contrôleur et non l’inverse. Personnellement, c’est une méthode qui ne me satisfait pas, car j’estime que c’est au contrôleur de passer les informations nécessaires à la vue et pas l’inverse.
      Ici, détrompes-moi si ce n’est pas le cas, le designer a libre accès aux variables de tout le scope. Ou alors j’ai raté quelque chose.

      Y’a t-il des avantages à ce que le template récupère de lui-même les variables ?

      Sinon, je trouve que la syntaxe ressemble au couple XML/XSL/, qui est assez déroutante au début 😉

      Merci.

      • Merci Max pour ta réponse, et pour me donner l’occasion d’écrire quelques mots de clarifications sur le projet FigDice.

        Les vues n’ont accès qu’aux données « mount »ées (soit injectées directement depuis l’extérieur (i.e. le contrôleur) soit tirées par la vue pendant son rendu, en activant des classes de fourniture de données (Feed)).
        La vue n’a accès à rien d’autre qu’à son « univers » (i.e. la réunion de ces deux sources de données). En particulier elle ne voit ni les variables globales ni les objets ou variables du scope enfermant l’appel à la fonction de rendu, etc.
        Elle n’a pas non plus accès en écriture, aux données de son « univers ».

        Le cas d’utilisation typique, de cette approche, est que le contrôleur de vue n’a besoin d’exister qu’en un seul exemplaire, ayant pour spécialité de simplement exécuter le template qui doit correspondre à l’URI demandée ; puis le travail à effectuer pour rassembler les données des vues peut être éclaté en composants, que chaque vue actionne à son gré.

        Exemple : un composant qui fournit le nombre d’items du shopping cart et le montant total ; un composant qui fournit le détail d’une commande ; un autre qui fournit la fiche profil de l’utilisateur connecté — etc.
        Ainsi, le designer de la vue peut choisr d’inclure une brique « Panier » dans l’écran, ou une zone « dernière commande » dans un coin — le contrôleur à proprement parler n’en sait rien. Les données de ces zones sont fournies par des classes Feed réutilisables dans d’autres vues, ou débrayables conditionnellement (directement depuis la vue).

        Concernant la syntaxe : c’est en fait très distant du XSLT (qui est verbeux, non linéaire, et à mon avis pas du tout Turing-complet mais je n’ai pas essayé de vérifier ce ressenti 🙂
        C’est en réalité simplement du HTML, avec un jeu d’attributs custom qui permettent d’exprimer les boucles, conditions et évaluation de variables.

        La contrainte « XML » n’est là en fait que pour faciliter le parsing… mais en investissant plus d’efforts dans le projet on devrait pouvoir s’en affranchir et rester permissif sur le HTML et ses tags pas fermés etc.
        En-dehors de cet aspect, c’est vraiment le HTML natif enrichi de tags « include » et autres choses de ce genre qui font que le template s’exécute comme un langage de programmation (linéaire, de haut en bas, pas comme l’ensembliste XSLT !)

        Si je peux répondre à d’autres questions, ou t’éclairer sur des cas concrets d’utilisation, ce sera avec plaisir !

        Gabriel

        • Il n’y a pas de quoi, si j’écris de mauvaises interprétations tu es bien sûr en droit de les corriger 😉

          J’ai pris le temps de la réponse, ce qui m’a permit de regarder un peu plus le code et les exemples fournis. Je comprends à présent mieux comment le système fonctionne.
          Ce que j’avais occulté, c’est justement la méthode mount(), qui va justement pousser les variables vers la vue, à la manière de la méthode set() écrite dans cet article (en très gros).

          Effectivement, le XSLT est trop verbeux pour pouvoir être une solution de templating (j’en connais un adepte 😉 ), autant se farcir le php brut. En fait, ce sont juste les balises comme <fig:dictionary name="Client" file="dic-client.xml" /> qui m’ont fait penser à ça, mais il ne s’agit ni plus ni moins que du xml.

          Concernant le code en lui-même, y’a t-il une raison d’avoir mis toutes les méthodes de la classe View en public ?
          Que se passe t-il si je fais :

          Sinon, en terme de performances, chacun sait que le XML est un format lourd à traiter. Sais-tu où FigDice se situe par rapport à ses concurrents qui usent des preg_replace() et ont une syntaxe ‘plus commune’ ?

          Merci.

          • Max,

            Ces méthodes publiques de la classe View me permettent de les rendre accessibles par la classe ViewElement (et d’autres classes du package).
            En Java j’aurais utilisé la notion de package protected pour ne permettre qu’aux classes du namespace, d’accéder à ces méthodes. En C++ j’aurais utilisé des friends peut-être.
            Ne sachant pas comment faire mieux à l’époque en PHP 5.3 (oui, le projet date…), j’ai laissé ça public, avec la documentation qui va bien. Je serais preneur d’un conseil pour implémenter la restriction de visibilité qui va bien, pour ces méthodes ! 🙂
            Aujourd’hui j’utiliserais peut-être des closures ou ce genre de choses pour gérer la visibilité intérieure.

            Concernant le mount : en effet le fait de l’utiliser depuis le contrôleur , rend possible l’utilisation de FigDice comme n’importe quel autre template engine. On passe alors un peu à côté de l’intérêt principal 😉 mais c’est un usage comme un autre.

            Question célérité : il y a en fait pas mal de preg_match dans le code, notamment pour extraire les expressions « inline » dans les attributs HTML natifs. Exemple :

            Ici les expressions entre { } sont évaluées par FigDice, et ont accès à toute sa force expressive (variables et fonctions etc.)

            Mais sinon le parsing du source XML est fait avec l’extension PHP de bas niveau XML Parser, basée sur la libxml. Le parsing est rapide (lecture linéaire, passe unique), mais je n’ai pas fait de benchmark. Ce serait intéressant d’en faire…
            Un des avantages est la facilité de localiser dans le fichier les « erreurs de syntaxe » (tant sur le plan XML que sur la couche « directives de template »).

            Le résultat du parsing dans la version actuelle n’est pas mis en cache — c’est à mes yeux le chantier le plus urgent de ce projet. Toutes les bonnes volontés qui nous lisent sont les bienvenues… ! 😉

            Mais pour le moment les performances en production même sur de gros trafics, ne m’ont jamais déçu.

          • Hello Max, je viens d’ajouter un peu de commentaires dans le premier des exemples que je fournis… C’est peut-être à cause de lui que le mount() t’avait induit en erreur ! 😉

            https://github.com/zzgab/figdice/commit/9d20fb1b0cb3303cfc7f08cedf1421bea0f72627

            PS : je bosse sur un allègement du parser pour qu’il accepte le HTML classique dans une future version, plutôt que d’exiger des tags bien fermés partout (même ceux que le HTML 5 définit comme n’ayant pas à être fermés). A suivre ! 🙂

        • Personnellement, j’aurais opté pour mettre ces méthodes en protected, et mis la classe ViewElement en héritage de View.
          Mais c’est personnel et pas forcément adapté. Il n’y a malheureusement pas en PHP beaucoup de solutions qui s’offrent à toi pour ce genre de problématiques.

          Sinon, je viens de comprendre comment fonctionnent les Feed, et je comprends à présent la vraie puissance de ton système.
          Je m’étais arrêté à la lecture de cet article, qui ne présente pas assez bien selon moi comment s’en servir, et des exemples fournis avec le code source, mais la doc m’en apprend bien plus.

          HS : J’ai l’impression qu’il manque l’exemple dans ton précèdent commentaire, non ?
          Sinon, pour marquer du code ‘inline’, j’utilise la balise <code>mount()</code>, et pour des pavés :

          • Oui ! il manquait effectivement un bout dans mon exemple (je ne saivais pas quel balisage utiliser pour les exemples de code 🙂 ). L’exemple était le suivant :

            On voit ici que l’attribut src de la balise img est composée d’une partie en dur, retranscrite telle quelle dans l’HTML de sortie, et d’une partie qui est l’évaluation d’un morceau de l’ « univers » de la vue FigDice. (Bien sûr cette variable_expr de l’exemple peut être toute sorte d’expression que le moteur sait comprendre.)

            Voilà pour l’exemple qui met en jeu des preg_match.

            Ta suggestion est intéressante ; mais sémantiquement ça me gêne car ViewElement n’est pas exactement une sorte de View. La hiérarchie me semblerait artificielle ici.
            En PHP 7 je peux faire des choses subtiles (injection de fonction anonyme d’accesseur, à la création des objets ViewElement mais j’ai des doutes sur l’efficacité en termes de consommation mémoire. A étudier.
            Autrement, plus basique, il y a l’utilisation des tags @internal dans les blocs PhpDoc. Ca t’aurait directement indiqué que cette méthode popStackData n’était pas pour ton usage public 🙂

            Merci pour ton appréciation de l’approche, en deuxième réflexion. Les exemples fournis dans le projet permettent peut-être de se faire une idée plus précise. C’est une approche originale que les autres moteurs que j’ai rencontrés n’offrent pas — or elle répond très bien à mes types de besoins, c’est pourquoi j’ai décidé de la développer.
            L’utilisation des FeedFactory pour instancier les Feed à la demande, permet d’y injecter silencieusement toutes les dépendances dont ils ont besoin (objets DAO ou connexion à la base de données par exemple) sans que l’auteur du template n’en sache quoi que ce soit. L’auteur et le développeur ont juste besoin de se mettre d’accord sur le dictionnaire de données : l’ensemble des Feed à disposition, et la structure de leurs valeurs de retour.

          • J’ai modifié ton commentaire avec l’exemple 😉

            C’est compris pour les preg_match, merci.

            Ma suggestion est intéressante oui et non : Comme tu le dis, sémantiquement si ViewElement n’est pas une sorte de View, alors il n’a pas à en hériter. Mais à l’heure actuelle, je ne pourrai pas te donner d’autre solution, excepté de faire une vérification sur la classe qui a appelé la méthode.
            Maintenant, est-ce un réel problème que ces méthodes soient publiques ?

            Concernant les Feed, ce qui m’a dérouté dans les exemples présents sur le Git est qu’à chaque fois, tu fais usage de mount(), aussi je ne comprenais pas comment s’en passer.

            Merci à toi, you’re welcome 😉

  2. Très joli quand on lit le code, mais une aberration conceptuelle. Tout le code est interprété dans un preg_replace, qui est une fonction lente. PHP est un langage interprété, on interprète une interprétation.

    • C’est la méthode la plus commune lorsqu’il s’agit de parser quelque chose, je n’ai rien inventé.
      Je ne dis pas qu’il n’y en a pas d’autre, comme Gabriel le souligne, mais s’en est une qui fonctionne, rapide à mettre en place et qui autorise n’importe quelle syntaxe.

      Si la fonction preg_replace() est lente, ce n’est en réalité pas un gros problème, puisque le code généré peut-être mis en cache très simplement. Il n’y a alors, plus d’interprétation à faire à chaque affichage.

      Pour le coup, je sens que l’on tend vers mon second paragraphe : ‘Oui mais PHP est déjà un moteur de templates’ 😉

  3. Bonjour,

    « Étant autodidacte dans l’âme depuis tout petit (je n’ai jamais suivi un seul cours d’informatique), »
    Oui, ça se ressent dans ce que tu fais, il manque des bonnes pratiques de programmation ainsi que quelques règles élémentaires, notamment :

    – Un nommage clair de tes classes (Tpl n’est pas clair ni compréhensible, content non plus)
    – Un respect du camelCase (filePath, fileContent)
    – Une exception moins généraliste que Exception serait bien aussi, mais demanderait ici un développement supplémentaire peut-être inutile.
    – Au passage, comment un filename peut devenir un filepath, une différence est à faire entre les deux, auquel cas il faudrait uniformiser les noms
    – Nul besoin d’autant de commentaires dans ta méthode output, un bon commentaire est un commentaire inexistant.
    – Ta méthode de parsage est peut-être un peu difficile à comprendre, notamment à cause de l’imbrication de ‘, n’hésite pas à utiliser des  » pour éviter ceci.
    – Il est fortement déconseillé de préfixer les méthodes privées par un _ (voir PSR)
    – Il faut rappeler le nom de l’attribut dans ton phpDoc, question de compréhension
    – Tu pourrais utiliser des ternaires pour alléger ton code, mais ça représente plus un choix personnel ça.
    – L’accolade des if, while et autre symbole de ce genre doit se situer sur la même ligne.

    Autre petite remarque au passage, on aura tendance à laisser la documentation sur 3 lignes minimum pour les attributs, même si tu peux le faire en une seule. Question de parsage et surtout de lisibilité.

    Je n’ai pas regardé plus en détail, mais je pense que tu pourrais très grandement optimiser ton code, le rendre plus léger et plus compréhensible. N’hésite pas à consulter le site phptherightway (http://www.phptherightway.com/) qui te guidera vers beaucoup de bonnes pratiques que tu ne connais peut-être pas.

    Autrement, je félicite grandement l’initiative d’ouvrir ce genre de blog ! 🙂

    • Bonjour Sakuto,

      Ayant été pendant longtemps un lecteur des tutos et du forum d’OC, cela me fait plaisir de te trouver ici 🙂

      Alors oui, il me manque certaines bases, pour sûr, mais je me soigne 😉
      Je vais essayer de te répondre point par point :
      – Je pensais Tpl clair, Tpl pour Template, visiblement ça ne l’est pas. content est le contenu une fois parsé.
      – J’ai du mal avec le camelCase : Je l’applique à mes fonctions et méthodes, il manque les variables et attributs, c’est vrai.
      – filename devient filepath par erreur, c’est en ne relisant pas son code qu’il se produit de telles erreurs.
      – J’ai tenu à commenter autant pour l’article, mais sûr qu’il n’y en ai autant besoin, surtout que le code est simple.
      – Je n’aime pas trop les guillemets doubles. Mais c’est personnel et dans ce cas là, vrai que ça n’améliore pas la lisibilité.
      – l’underscore présent est uniquement là pour indiquer que, dans le code de la classe elle-même, aucun appel ne sera fait à cette méthode mais uniquement dans le code interprété (ou parsé)
      – Je ne savais pas pour PhpDoc.
      – Les ternaires font perdre en lisibilité. Pour un pseudo tuto, j’ai préféré m’en passer, mais j’en abuse habituellement.
      – Les accolades sur la même ligne, je n’aime pas, Netbeans non plus apparemment. Je me mettrai au PSR2, et lui également 😉

      En l’état, le code n’est pas optimisé ni très ‘Right Way’, surtout parce que c’est un article et non un code à distribuer. J’imagine qu’il vaut mieux tout de même implémenter ces bonnes pratiques afin de prévenir que ce code ne se retrouve en prod quelque part.
      C’est une réflexion que je ne m’étais pas faite, je tâcherai à l’avenir d’en prendre compte.

      Merci bien pour tes conseils judicieux 😉

      • Je sais que c’est dur à croire, mais je reste une personne normale 😀
        – Un raccourci n’est jamais un nom clair, Template sera toujours mieux que tpl, parsedContent sera mieux que content.
        – C’est un détail à travailler, ça viendra avec le temps je suppose 😀
        – A changer donc.
        – Autant montrer les bonnes pratique, si ton code nécessite des commentaires, il faut le séparer en plusieurs méthodes plus explicite
        – /
        – C’est la même chose, et c’est à éviter :p
        – /
        – Pas forcément, pouvoir résumer 5 lignes en une permet de simplifier la lecture.
        – Netbeans n’est visiblement pas correctement configuré pour le PHP et reste sur les conventoins Java
        Sinon, pour tes problèmes de conventions non respectée, tu peux commencer par utiliser un vrai IDE comme PHPStorm (gratuit pour les étudiants, et sinon vraiment peu cher) qui intègre toutes ces conventions et intègre aussi un linting pour t’indiquer quand tu ne les respecte pas. Tu dois certainement pouvoir faire le même sur Netbeans.

Laisser un commentaire

Votre adresse mail ne sera pas publiée.

*

© 2017 Max-Koder — Propulsé par WordPress

Theme par Anders NorenHaut ↑