Comment faire un code PHP « propre » ?

Bonjour les agrumes !

Ça fait des années que je programme (ou plutôt) bricole en PHP. D’après mes archives, plus de 10 ans. Avec le temps, j’ai pris des habitudes de vieux, mais pas forcément clean.

Mes scripts adoptent cette structure, souvent monofichier : Include vers un ou des fichiers fonctions Une partie de code en HTML (head, menu etc) mon code PHP, avec un switch pour les différentes « pages » la fin du code HTML

C’est pas forcément très clean. Je voulais connaître vos tuyaux pour rendre ça plus maintenable.

Bonne journée :-)

Tout dépend du projet, mais généralement un design pattern adapté sera à privilégier.

En PHP le plus courant est le MVC qui est utilisé par la plupart des frameworks.

Tu auras d’un côté tes models, qui représentent tes données brutes et communiquent avec la BDD.
Ensuite les controllers vont traiter les données pour les récupérer ou les modifier.
Puis les vues vont permettre d’afficher ce que tu veux.

Je t’invite à aller voir comment les principaux frameworks (comme Laravel qui est à la mode en ce moment) s’en sortent pour organiser le code

En utilisant un framework ou en imitant la structure d’un framework.

Pas besoin d’utiliser un gros framework lourd avec des fonctionnalités dont tu te passes très bien aujourd’hui, si tu n’as pas l’habitude. Un « micro framework » ferra l’affaire si c’est juste pour mieux structurer et organiser tes applications.

Hello,

Pour faire du code propre en PHP c’est comme tous les langages, il faut utiliser les bons patterns etc. Il y a beaucoup de choses à dire…

Mais une bonne base c’est peut être ce livre: clean php

Note: ce livre vend un peu du rêve avec son titre mais en réalité c’est plutôt sur les basics de comment bien coder en php

Pour faire un TL;DR :

1. Utiliser les namespaces
2. Utiliser composer
3. Utiliser les design pattern
4. Utiliser SOLID

En dehors de ce qui est propre à PHP, je peux peut-être conseiller ce que j’applique à tous les langages :

• Utilise des noms de variables ou de fonctions complets et explicites, évite les abréviations. Arrête-toi et réfléchis à leur clarté, si ça doit être ambigu mets un commentaire.
• Dès ton code atteint un certain niveau de complexité (côté traitement, pas côté de vue), fais des classes.
• Fais des commentaires au-dessus des fonctions, avec paramètres, retour, but, types.
• Mets des commentaires écrits dans un langage clair lorsque que quelque chose doit être ambigu.
• Saute des lignes pour encourager la lecture.
• Dès que tu as des types complexes composés de plusieurs types, fais des annotations (si le langage ne supporte pas les annotations mets-les en commentaires)

Salut,

D’avance je précise que je ne travaille plus avec PHP mais j’ai le sentiment que ta question s’étend à d’autres langages, donc je me lance.

De manière générale, je pense qu’au-delà de demander ce qu’il faut faire pour aboutir à tel résultat, je pense qu’il faut aussi se demander ce qu’il ne faut pas faire. Je me permets un parallèle avec la vie réelle : si tu veux rester en bonne santé, il ne faut pas fumer, ne pas consommer de drogue dure, etc. C’est des choses qu’on dit assez peu souvent au détriment de « il faut manger cinq fruits et légumes par jour ». En bref, la connaissance négative est selon moi plus robuste que la connaissance positive.

Par exemple si je suis d’accord sur certains points avec @Nek, le troisième point pour moi ne me semble pas obligatoire. Si dans ta démarche tu ne rencontres aucun problème que les design patterns résolvent, ils n’ont alors absolument aucune utilité. C’est même pire : tu crées un problème en utilisant un design pattern incorrectement. On appelle ça humoristiquement la patternite. Il vaut mieux s’en passer dans certains cas.

De même, si ton problème c’est la maintenance, pose-toi la question suivante : es-tu le seul à travailler sur ce projet ? Est-il d’envergure ? Si ce n’est pas le cas, utiliser un framework comme symfony peut sembler overkill. Symfony résout un problème connu : concilier le travail de plusieurs développeurs et offrir un cadre de travail. Mais bosses-tu en équipe et as-tu besoin de ce cadre ?

En bref j’essaie de garder en tête KISS et YAGNI à chaque fois que je bosse sur un projet. Cela ne veut pas dire que je réussis à les appliquer tout le temps…

Sinon, essayer d’avoir des fichiers avec un nombre de lignes limité (de même que pour tes fonctions, méthodes de classes etc.) me paraît aussi être un bon compromis.

Salut,

La réponse va aussi changer énormément selon que ce soit un projet pro ou amateur.

Si c’est un projet pro, tu as tout intérêt à passer à la formule framework, surtout si vous développez à plusieurs.

• Le framework t’oblige à respecter les bonnes pratiques: séparation des responsabilités, maintien d’un code lisible pour tous, documentation, tests unitaires, …
• Il te permet aussi de mettre rapidement en route un certain nombre de modules récurrents de façon fiable. Pour le web, une page de connexion avec ou sans réseaux sociaux et un dashboard, des API REST, des news ou un blog, des fiches produit, un système de paiement, un panel admin, etc. C’est tout du temps que tu peux consacrer à ton véritable métier, plutôt que de te casser la tête sur des fonctionnalités de base.

Le but du projet pro, c’est d’avoir rapidement et à moindre coût un truc fonctionnel. Tout le temps que tu peux gagner à ne pas réinventer la roue est du temps gagné et donc de l’argent.

Par contre pour un projet amateur, tu n’as bien souvent pas à t’emcombrer de tout ça.

• Tu es seul dans ton code et tu ne prévois pas de le montrer à d’autres ? osef de la lisibilité, des commentaires et de la documentation, tant que t’y retrouves toi-même. Si ça fait 10 ans que tu développes, du connais certainement déjà ce dont tu as besoin ou pas pour pouvoir te relire.
• La séparation des responsabilités, le MVC et toutes les fonctionnalités fournies par le framework c’est cool, mais ça vient avec un coût non négligeable en dépendances et en performances si tu n’en utilises pas le 80%. C’est valable aussi avec l’écosystème Docker & Co, et aussi dans le front avec Angular ou React. Le fait est qu’on empile les couches, c’est bien parce que c’est modulaire et réutilisable, mais mine de rien, à la fin, ça bouffe.
• Les tests unitaires ne sont jamais fun à écrire et en fait c’est même difficile de faire du TDD vu que la spécification n’est pas vraiment écrite à la’vance. D’ailleurs pourquoi s’embêter à écrire une spec ? Bien souvent on développe au fil de l’eau en fonction de ses idées et envies, et donc on n’écrit pas de tests non plus.

Bref, c’est tout le contraire de ce qu’on fait dans un projet pro. Parce que le but avant tout, c’est de s’amuser et/ou de progresser, pas de gagner du fric rapidement. C’est pas grave si on a réinventé la roue, c’est tellement plus chouette que de copier-coller du code écrit par d’autres.

A moins que ton objectif soit précisément d’apprendre à utiliser un framework, tu n’en as probablement pas besoin pour un projet amateur. Donc à toi de voir ce qui t’intéresse.

Personnellement je suis des gens qui pensent que tu as tout intérêt à utiliser un framework pour le moindre projet, même tout seul dès qu’il ne devient plus trivial. Parce que le but d’un framework, c’est surtout de te permettre de te concentrer sur le code utile : tu délègues une grande partie du boilerplate code (le code sans valeur ajoutée qui sert juste à faire que « ça marche ») au framework. Pour reprendre les arguments énoncés :

Ça fait plus de 10 ans que je développe, et à chaque fois que je reprends un de mes projets que je n’ai pas touché depuis longtemps (ou un bout du projet que je n’ai pas touché depuis longtemps), je suis très content d’avoir un code lisible et ou les parties non-triviales sont documentées. Sans quoi je perds un temps monstrueux à essayer de comprendre pourquoi et comment ça fonctionnait.

Note que « longtemps » dans ce contexte, c’est environ un mois.

Ça peut être très vrai ou complètement faux, selon ton utilisation du framework et le framework lui-même. Ce qui est important pour les performances, en réalité, c’est de comprendre ce que tu fais. Ne pas utiliser de framework n’a jamais rien rendu magiquement plus rapide. Parfois c’est le contraire, par exemple en JS si tu manipules le DOM directement (via jQuery ou autre), tu peux très vite te retrouver avec un système plus lent qu’en utilisant un framework réactif qui possède un DOM virtuel.

Assez d’accord pour les specs. Par contre, les tests unitaires peuvent être intéressant. Pas pour avoir une jolie couverture de code, mais pour vérifier qu’une fonction non-triviale fait bien ce qu’elle doit faire, y compris (surtout ?) aux limites, et pour des questions de non-régression.

Ça n’est pas le fonctionnement d’un framework que tu décris là, c’est le fonctionnement d’un mauvais développement, qui peut très bien se faire sans framework. Je le sais, je l’ai pratiqué

Et donc, connaitre un framework adapté à tes besoins t’aidera beaucoup, sur tes projets amateurs aussi.

Et aussi pour s’y retrouver sur le projet en y revenant longtemps après : les tests aident à la documentation, ça permet de se souvenir facilement de ce que devait faire telle ou telle fonction, comment devait se comporter tel objets, etc.

Merci pour vos retours. Comme vous dites, c’est différent quand on code solo ou à plusieurs, en amateur ou en pro. C’est de l’amateur solo. J’ai réfléchi pour voir ce qui me pose problème, et c’est l’aspect « code spaghetti ». Je développe un prototype, et petit à petit, il monte en complexité. J’avoue que je n’ai pas trouver de recette miracle, d’où ce topic. Merci pour vos références :-)

Je développe un prototype, et petit à petit, il monte en complexité.

J’avais pas osé en parler encore, mais c’est un syndrome typique. Un jour j’ai un peu rage quit des frameworks conventionnels en me disant "je n’ai pas besoin de tout ça, je vais partir d’une feuille blanche". Bon, pas vraiment blanche j’étais parti sur Silex/Pimple à l’époque, mais presque blanche quoi.

Sauf que, arrive plusieurs moments:

• J’ai besoin de travailler avec des données, ok, bon, installation de doctrine dbal (parce qu’on veut pas l’ORM parce qu’on veut faire simple et rapide)
• Ah ouais et j’ai besoin de templates aussi. Bon bah on va installer twig c’est pas grave.
• Hum; il me faut à présent travailler avec des images et les resizer, bon j’installe la lib
• etc etc etc

Au final je me retrouve avec un gros projet, qui a une sorte de framework maison à l’intérieur, avec rien d’optimisé (cache & co), et surtout j’ai du réécrire une partie du code qu’on peut trouver dans les plugins de frameworks (ie: bundle symfony). Doctrine dbal pour aller plus vite ? Vraiment ? Doctrine ORM qui vient de base avec Symfony c’est si simple à utiliser et si efficace. A quel moment dbal est plus efficace dans mon dev ? Jamais en fait.

Concrètement, j’ai fait beaucoup de travail pour rien, mon projet aurait été codé super vite avec Symfony, et en plus il serait reprenable par n’importe qui (bon, ce qui n’était pas le but).

Depuis, je suis team framework pour le moindre truc. L’approche de Symfony où tu commences avec rien et ça rajoute les configs au fur et à mesure, je suis fan.

Désolé pour ce petit hors sujet par rapport au titre original, mais ça répond plus ou moins aux questionnements de l’auteur je pense.

En fait @Nek on peut faire le même parallèle avec Flask (en python) qui consiste en un micro-framework ou tu dois un peu tout ajouter toi-même, et Django ou tu as une structure bien établie.

Je pense qu’il faut vraiment faire attention à garder la tête un peu en dehors des détails techniques et s’intéresser au produit.

J’ai même eu une discussion avec @entwanne qui disait qu’il utilisait aiohttp là où je me suis arraché les cheveux avec cet outil : simplement parce que les besoins ne sont pas les mêmes.

Des besoins, ça évolue. Tout le temps. Donc si tu pars avec un truc bien fourni, il peut se révéler encombrant à long terme (car il peut ne plus répondre correctement à tes nouveaux besoins) comme il peut se révéler bénéfique (car il y répond toujours très bien et ça prend peut de temps pour le faire).

De même, si tu pars avec quelque chose de minime, ça peut se révéler chronophage et catastrophique de rajouter brique sur brique comme ça peut se révéler bénéfique car il suffit juste d’écrire 5 lignes pour connecter une nouvelle route ; pas besoin de bouger des montagnes et écrire une nouvelle classe verbeuse avec 10 injections de dépendances juste pour faire cuir un œuf (celle-là je la dédie à @nohar).

(J’ai bien envie de me remettre à PHP d’un coup…)

Je pense qu’il faut différencier l’approche procédurale et l’approche objet. Pour avoir longtemps développé en procédural en PHP, je peux dire que le passage de l’un à l’autre se fait sentir. Je développais un peu comme toi, un fichier d’entrée qui incluait les pages à rendre (j’avais fini par avoir un fichier pour le traitement, un autre pour la vue), des fichiers avec des fonctions, etc.

Quand je me suis mis à l’objet, ça a été un peu dur. J’ai codé un mini framework MVC maison, qui faisait le boulot pour mes besoins (plus par apprentissage que par réel besoin). J’ai plongé dans Symfony en même temps, et je n’en suis plus jamais sorti.

Selon moi, peu importe que ce soit un projet perso ou pro et qu’on soit seul ou plusieurs dessus. Le framework est bénéfique : normalisation, communauté, pas besoin de réinventer la roue, etc. Et je pense que l’argument disant que si on est seul, pas besoin d’un framework, est fallacieux : on ne sait jamais si on ne sera pas rejoint un jour ou l’autre, même sur un projet perso. Et ce jour là, on est bien content d’être passé par un framework.

De la même manière, avoir un framework dont on se sert d’uniquement 20% des capacités est un faux débat. Je parle pour Symfony parce que c’est celui que je connais: il est coupé en components, si bien qu’on a besoin d’installer que ce qui est nécessaire.

Pour moi, quand on en vient à se poser la question de "comment faire un code plus propre en PHP", c’est qu’il est temps d’utiliser un framework. Peu importe les projets (attention, je parle de projets un minimum conséquents; évidemment si le projet consiste en une seule page, aucun intérêt) et le nombre de développeurs dessus.

Assez d’accord pour les specs. Par contre, les tests unitaires peuvent être intéressant. Pas pour avoir une jolie couverture de code, mais pour vérifier qu’une fonction non-triviale fait bien ce qu’elle doit faire, y compris (surtout ?) aux limites, et pour des questions de non-régression.

Je n’ai jamais dit que les tests n’étaient pas utiles, seulement qu’ils étaient barbants à écrire.

Si même en amateur on peut s’y tenir, c’est bien ! Moi perso j’ai du mal…

Et aussi pour s’y retrouver sur le projet en y revenant longtemps après : les tests aident à la documentation, ça permet de se souvenir facilement de ce que devait faire telle ou telle fonction, comment devait se comporter tel objets, etc.

JE suis d’avis que si on choisit des bons noms de classes, de méthodes et de variables, dans la plupart des cas on n’a pas besoin de documentation. Mais évidemment c’est autre chose quand on sait que quelqu’un d’autre va lire le code.

Ce qui est important pour les performances, en réalité, c’est de comprendre ce que tu fais.

Alors là je suis totalement d’accord ! Le souci c’est que souvent, le framework, c’est de la magie, c’est une boîte noire, et régulièrement c’est vendu comme ça. On sait grosso modo comment ça marche, mais pas en détail, voire même on s’en fout un peu tant que ça fait ce que ça doit faire plus ou moins correctement. Du coup on perd un peu la maîtrise de ce qu’on fait. ON fait confiance à un bulldozer alors que peut-être qu’en trois coups de pelle on avait l’essentiel. KISS.

JE suis d’avis que le choix du framework (ou pas) doit être éclairé. Fondamentalement on ne peut pas te contredire quand tu dis:

Et donc, connaitre un framework adapté à tes besoins t’aidera beaucoup, sur tes projets amateurs aussi.

Car sinon, pour développer un site web, on commencerait par développer son propre langage parce que PHP fait trop de choses. ET il faut que ça tourne sur un OS donc on développerait son propre OS aussi. Et tant qu’on y est pourquoi ne pas commencer par assembler des transistors soi-même ?

Donc oui, on a forcément besoin d’un cadre adapté à ses besoins. PHP lui-même est un framework, si on y regarde bien (IL est de base beaucoup plus spécialisé que ne le sont Java ou Python qui eux sont des langages plus généraux).

Malheureusement, j’ai l’impression que souvent, les frameworks, c’est vendu comme "prend ça et ça résoudra tout tes problèmes". ET les gens foncent.

Cette philosophie a entres-autres donné JQuery. Voir des phrases genre "JE code en JQuery" me hérissent les poils. Non, JQuery n’est pas un langage ! Conséquence de débutants qui ne connaissent pas les fondamentaux de JavaScript dans le navigateur avant de foncer dedans à tête baissée. Bon, il semble que la vague JQuery soit plutôt derrière nous en 2020. Maintneant on est plutôt dans les vagues VueJS et React.

Alors maintneant, si tu sais ce que fait <insère le nom d’un framework ici> et qu’il est adapté à tes besoins, bien sûr, utilise-le ! Tu serais bête de passer à côté puisqu’il fait en grande partie ce que tu veux.

Cependant, je suis persuadé qe pour bien profiter d’un framework, il faut d’abord avoir appris à coder sans, et qu’il ne sert à rien de le dégainer systématiquement.

Ca c’est vu avec JQuery (oui désolé j’ai une dent contre lui). "JE veux changer la couleur de fond quand on passe la souris ici" => "Prends JQuery !" alors qu’il suffisait de quelques lignes de CSS. "J’aimerais faire cett effet-là" => "En JQuery on fait comme ça" sans savoir si l’auteur utilise déjà JQuery ou non.

Je développe un prototype, et petit à petit, il monte en complexité.

J’avais pas osé en parler encore, mais c’est un syndrome typique. Un jour j’ai un peu rage quit des frameworks conventionnels en me disant "je n’ai pas besoin de tout ça, je vais partir d’une feuille blanche". Bon, pas vraiment blanche

C’est sûr que vu comme ça, le framework dès le début aurait été mieux. Comme toujours: on est toujours plus malin après. Mais tu étais loin de la "feuille blanche", si on regarde bien. Tu avais déjà un pied dedans:

J’ai besoin de travailler avec des données, ok, bon, installation de doctrine dbal (parce qu’on veut pas l’ORM parce qu’on veut faire simple et rapide)

Tu aurais utilisé PDO, inclus de base dans PHP, c’était pareil, et encore plus simple pour commencer.

Note qu’on peut parfaitement se protégé contre les injections en PDO seul sans que ce soit nécessairement compliqué, donc ce n’est pas un argument suffisant pour être contre.

Ah ouais et j’ai besoin de templates aussi. Bon bah on va installer twig c’est pas grave.

ON oublie trop souvent que PHP lui-même est un moteur de template, et qu’à la base, c’est dans cette optique qu’il a été conçu.

Pour peu que tu t’en sois tenu à une séparation entre le traitement des données et leur affichage (en faisant un MVC ultra-simplifié), twig n’était probablement pas tant une obligation. Il n’apporte qu’une syntaxe avec quelques sucres, et, effectivement, la certitude de bien séparer les responsabilités d’affichage. Dans ce sens s’est déjà un framework.

EDIT: doublon