Les bonnes pratiques de programmation en PHP

[Alorsladaccord]

Bonjour,

Finalement, j'ai décidé de me reprogrammer un site internet maison, conforme à mes besoins. J'en avais déjà créé un il y a maintenant presque dix ans - le temps passe vite - et il était très réussi, du moins côté client. Mais les scripts étaient tout en fouilli, si un autre développeur avait dû le reprendre il s'en serait arraché les cheveux.

Donc cette fois, je voudrais coder un truc propre, bien organisé, avec une architecture pro, donc standard, c'est-à-dire portable d'un webmestre à un autre.

Alors voilà ma question : existe-t'il des modèles à suivre pour organiser les fichiers d'un site web, c'est-à-dire quels objets et fonctions doivent être rangés où et appelés quand, etc... ?


Merci d'avance :!:

 

[rick38]

En un mot, MVC.

Déjà, pas une ligne de code ne doit se trouver ailleurs que dans une classe, faire du PHP tout objet est la 1ère best practice.
Une classe pour le header, une classe pour le footer, une classe pour la colonne du menu, une pour le contenu de la home, etc, etc.
Ensuite MVC ça veut dire un fichier php pour le contrôleur, un fichier php pour le modèle, un fichier pour la vue. La vue c'est le HTML, le modèle c'est une classe avec des fonctions qui accèdent à la table de la base de données, et le contrôleur contient des actions (supprimer/ajouter/etc).
Et un contrôleur global, le index.php, qui dispatche à un contrôleur (une page) avec des include en fonction de l'url demandée.

Bref en faisant une recherche du genre "programmer MVC en PHP" sur Google il y a des infos.

Mais concrêtement, la plupart des gens optent pour un framework, Zend ou Symphony, et il y en a d'autres plus légers en cherchant simple php framework mvc sur google, qui font justement tout ça.

 

[Blount]

Pas du tout convaincu par rick38.
C'est n'importe quoi de dire que tout doit être objet.
Personnellement, j'ai des projets avec Zend Framework (objet) et d'autre avec un code plus "simple" (procédural/objet), quand ce n'est pas nécessaire d'avoir un bazooka …
Ce n'est pas l'objet qui fait le bon code.

Quelques bonnes pratiques (de mon point de vue) :
- objet ou non : pas de duplication de code.
- bien séparer le code PHP (accès BDD, traitement d'infos, etc : Controller/Model) du HTML (Vue) au minima.
- user correctement des "require" (function, config, etc).
- garder ton code uniformément structuré. Ne pas avoir une façon de faire aujourd'hui et le contraire le lendemain et de surtout pas avoir les 2 en même temps.

Bref, peu importe avec/sans framework, objet/procédural, etc. Le tout est de structurer correctement ton code.
Ce qui est évidemment plus facile à dire qu'à faire

 

[Marie-Aude]

Blount est beaucoup plus réaliste que rick38

Le MVC n'est absolument pas une condition de "portabilité" et on peut faire du code dégueulasse en MVC et très propre en procédural.

Aux conseils de Blount je rajouterais

- convention de nommage claire et structurée dans tout ton code, éviter les noms de fonctions / variables trop elliptiques, six mois après on n'y comprend rien, mieux vaut un nom de fonction à rallonge et compréhensible

- documenter à outrance dans ton code, en début de fonction indiquer les paramètre, l'objet, marquer les fin de if / foreach etc avec des commentaires, dans le html marquer les fins de conteneur

- ne jamais hardcoder les variables dans les fonctions. Si tu ne fais pas d'options enregistrées en base de données, regrouper tes variables globales dans une classe (POO) ou un fichier (procédural) et les utiliser de façon globale, ça te permet de les changer rapidement (ça rejoint "pas de duplication de code"). Solution de facilité quand je suis la seule à les modifier, ça évite de faire une interface

- pas de notation résumée des balises (<?php et pas <?, préférer les structures longues pour les tests, etc...

- développer en mode strict avec tous les avertissements et les traiter TOUS

Après le reste c'est un peu comme le "style" tu as la grammaire, le vocabulaire, et avec ça tu fais un Philippe Djian, un Closer ou un Victor Hugo.

"Perso" voilà comment je m'organise (en procédural ou en POO, mais pas en MVC) :
- un dossier pour tous les "assets" (js, images, css), séparés par type, et à l'intérieur des types, quand c'est un gros dossier, par fonctionnalité
- un dossier pour l'admin
- un dossier pour les fonctionnalités globales, qui peut être séparé en sous dossiers (la structure qu'on retrouve dans les sous dossiers des assets)
- un dossier pour le front-end et tout ce qui est fonction d'affichage, qui peut être séparé en sous dossiers (correspondant aux fonctionnalités globales)
- un dossier pour les templates (pareil, avec des sous dossiers)

on n'est pas très loin de l'architecture MVC en fait, mais plutôt avec un fusil à pompe, pas un bazooka

 

[zeb]

Idem.

J'ajoute juste que je fais mon choix "objet ou pas" dans un projet mixte en fonction de la complexité de l'élément à traiter ou en fonction de l'intérêt que je peux tirer a centraliser un aspect.
J'ai par exemple tout ce qui concerne la base de données géré dans un objet, tout ce qui concerne les données d'une page dans un objet, idem pour les rubriques du site, ce qui touche a l'encodage des données (bbcode, xml, html, ...) etc ...

Le "tout objet" me semble une mauvaise option pour le web dans la mesure ou on a vite fait d'exploser la mémoire par la relative facilité a instancier tout et n'importe quoi quand on vas trop loin.

 

[franckM]

Perso j'ajoute une notation cohérente pour les variables et uniforme dans tout le projet , par exemple j'utilise toujours la notation hongroise où je préfixe un l pour une variable locale et un p pour une variable paramètre par exemple du style : $lmaVariable ou $pmaVariable

Egalement comme dit plus haut toujours documenter les méthodes en en-tête en mettant bien les paramètres, leur description, leur type et ce qui est retourné par la fonction notamment le type retourné. Avec un logiciel comme Eclipse, cela permet de pouvoir activer l'autocomplétion quand on y fait appel si le type retourné est un objet.

 

[Alorsladaccord]

Bonjour,

Merci pour toutes vos réponses.
Concernant le modèle vue controleur (MVC) évoqué plus haut, j'ai lu dans un bouquin PHP qu'il ne se prête pas trop à la programmation PHP.
Pour ce qui est de la programmation objet, c'est comme ça que je veux coder mon site car ce principe m'intéresse sur le plan intellectuel.

A part ça si je voulais résumer mon premier message, je crois que ce que je cherche est en fait un "framework". Donc plutôt que de réinventer la roue, lesquels conseillez-vous ? Il y a zend, j'ai lu aussi que cakePhp est bien.
Mais à vrai dire, je ne suis même pas certain d'avoir bien capté ce qu'est un framework. Est-ce un plan d'organisation des fichiers ? Et pourquoi y'en-a-t'il de plusieurs sortes ? C'est pour coder différents types de site (forum, blog...) ?

Merci d'avance

 

[Doubrovski]

plutôt que de réinventer la roue

Tu vas te faire remonter les bretelles par Zeb

Un framework c'est un ensemble d'outils donnés dans un langage (un ensemble de composants logiciels), pour aider un développeur à coder plus vite, plus proprement. Avant de coder plus vite il faut quand même compter le temps de formation...
Certains frameworks sont plus directifs que d'autres (certains imposent la structure de dossiers, d'autres non). En PHP tu as Symfony2, Laravel, Zend, Cake...

J'aime assez bosser avec des frameworks, mais attention quand même, c'est souvent des usines à gaz. Je suis pas sûr que ce soit la meilleure solution pour une structure de petits sites persos. Personnellement je me dirige vers des frameworks javascript légers.

 

[Marie-Aude]

Mais à vrai dire, je ne suis même pas certain d'avoir bien capté ce qu'est un framework. Est-ce un plan d'organisation des fichiers ? Et pourquoi y'en-a-t'il de plusieurs sortes ? C'est pour coder différents types de site (forum, blog...) ?

C'est une sur-couche, comme te l'as dit Doubrovski

A partir du moment où tu codes des fonctions que tu réutilises ensuite (comme par exemple une fonction de validation des numéros de téléphone, que tu vas utiliser dans différentes fonctions / formulaires ) tu commences un "framework".

Tu peux te le construire toi-même aussi (c'est ce que je fais sur WordPress, où au lieu d'utiliser de nombreux plugins qui communiquent "moyen" entre eux, je me suis fais mon propre ensemble de fonction pour gérer les champs personnalisés, les pages d'options, etc...)

Utiliser un framework permet d'aller plus vite dans le développement, mais fondamentalement, prend en charge une partie des opérations de base, il n'apprend donc pas à "bien coder".

De plus, tu dois "apprendre" le framework

Effectivement, pour des sites "petits à moyens", c'est une enclume pour écraser une mouche.

Et en dehors d'une organisation des fichiers imposée, un framework ne force pas à "bien coder". Par contre, ça peut être intéressant de regarder comment ils sont faits, pour comprendre leur logique.

Pourquoi il y en a des différents ? Ben pourquoi il y a différentes voitures ?

 

[zeb]

Tu vas te faire remonter les bretelles par Zeb

:lol:

Note que framework ou pas a la décision de démarrer un projet tu te retrouvera de toute façon avec un framework au final si tu organise bien ton code car tu mutualisera certaines fonctions au seins de ton propre "framework".
L'avantage de s'en passer c'est de ne retenir que ce que tu as besoin vraiment et de ne pas t'encombrer de superflu. A noter que sa réalisation est un pied a l'étrier de la programmation et une très bonne approche de l'optimisation du code au travers de la structuration.

Note aussi que certains framework ne sont pas forcement supportés par n'importe quel environnement serveur sans manipes "compliquées".

Pour la réinvention de la roue (vaste débat) rien n'exclus d'aller piocher le nécessaire ailleurs pour l'intégrer chez toi ... l'idée c'est de ne pas importer un package complet pour deux fonctions utiles comme le font beaucoup de codeurs de m****.

edit > les framework (on va dire bibliothèque de fonction pour faire "simple") existent côté serveur (ex : en php) comme côté client (ex : javascript)

 

[frenchhorn]

Concernant le modèle vue controleur (MVC) évoqué plus haut, j'ai lu dans un bouquin PHP qu'il ne se prête pas trop à la programmation PHP.

dans quel bouquin as tu lu ceci? MVC s'adapte très bien à php...

Bonjour,
Pour ce qui est de la programmation objet, c'est comme ça que je veux coder mon site car ce principe m'intéresse sur le plan intellectuel.

oui, même si tu ne fais pas du 100% objet, c'est necessaire d'avoir de jolie classes plutot que des include de fonction. organise ton code sous formes de classes OO.

A part ça si je voulais résumer mon premier message, je crois que ce que je cherche est en fait un "framework". Donc plutôt que de réinventer la roue, lesquels conseillez-vous ?

les framework que tu cite, si je ne me trompe pas utilise le MVC et programmation objet...

mais effectivement tu vas devoir apprendre son utilisation...

 

[p0k3]

J'utilisait CakePHP qui était simple et efficace pour des petits sites (type Site Vitrine + Blogs) ou autres.
Mais depuis, CakePHP 3... je suis perdu...

Bref, comme dans tous les langages de prog :

- DRY : Don't repeat yourself -> On ne réécrit pas 20 fois la même chose
- Fat Model Skinny Controller -> Dans le cas d'un MVC, le modèle doit contenir la logique modèle, une fonction du controller ne doit contenir que 5 ou 6 ligne de codes :
- Requête, Rendu
- KISS -> Keep It Simple, Stupid ! (Ne voyez pas d'insulte) il faut rester simple. Toujours chercher à simplifier son code.
- Ne pas ré-inventer le fil à couper le beurre... Bah oui, ça a déjà été écrit par qqn d'autres, pourquoi le réécrire ?
- Lisibilité -> Est-ce que ce que j'écris est lisible par quelqu'un d'autre ? Faites l'expérience de faire lire votre code par un neophite et bien il doit comprendre la logique du code

J'avais fait un article sur mon blog à ce sujet (www)

 

[Alorsladaccord]

Bonjour à tous,

Bon passons sur les "frameworks", je cherche simplement un plan classique pour organiser mes fichiers. Par exemple :
Index.php
-> include fonction.php puis + header.php + page.php + footer.php.
C'est tout ?

Mais en fait, j'ai une autre question : n'est-ce pas une erreur de coder son script à soi dans son coin ? J'ai fait comme ça la dernière fois et de tout mon travail (énorme : forum perso, admin, historique, zone mp, etc... etc...) il ne reste simplement rien du tout : que dalle, zéro.
Donc n'est-ce pas plus judicieux de travailler sur un projet déjà existant (wordpress, dotclear, IPB...), de comprendre le fonctionnement général puis de coder les pluggins dont on a besoin ?
La réponse m'apparait être oui, bien entendu. Le problème c'est que c'est un gros gros boulot pour démonter les scripts en question, les analyser etc... Alors y'a-t'il des méthodes particulières pour ça ? Je veux dire, pour analyser et comprendre la structure des gros scripts tels que ceux-ci dessus.

Merci d'avance.

 

[zeb]

et de tout mon travail (énorme : forum perso, admin, historique, zone mp, etc... etc...) il ne reste simplement rien du tout : que dalle, zéro.

La vrai question c'est pourquoi il ne te reste rien ...

 

[Alorsladaccord]

Non, ça ça n'a aucune importance. C'est simplement parce qu'à l'époque j'ai jugé bon de passer sur un forum IPB et j'ai laissé tombé ces scripts perdus depuis je ne sais trop où et désormais obsolètes de toute façon.


Donc la question ci-dessus reste valable : site perso ou travail sur script existant ?

 

[zeb]

si la question reste valable car un "script perso" ça peut être aussi un "script existant".
Bref tu te demande si tu passe du temps a coder ou utiliser un CMS quelconque et ça dépend de plusieurs facteurs comme l'argent, le temps ET le type de projet (faisabilité)

 

[Marie-Aude]

La réponse m'apparait être oui, bien entendu. Le problème c'est que c'est un gros gros boulot pour démonter les scripts en question, les analyser etc... Alors y'a-t'il des méthodes particulières pour ça ? Je veux dire, pour analyser et comprendre la structure des gros scripts tels que ceux-ci dessus.

En ce qui concerne WordPress, il y a toute la lecture du Codex, qui documente tout, et qui est structurée, débutant, développeurs, etc...

 

[Alorsladaccord]

si la question reste valable car un "script perso" ça peut être aussi un "script existant".
Bref tu te demande si tu passe du temps a coder ou utiliser un CMS quelconque et ça dépend de plusieurs facteurs comme l'argent, le temps ET le type de projet (faisabilité)

Plus précisément, je demande s'il vaut mieux coder son propre script de A à Z ou alors développer sur de l'existant, quite à passer beaucoup de temps à comprendre les scripts sur lesquels on veut greffer ses propres développement. Et je crois que cette deuxième solution est largement préférable, encore faut-il avoir le temps et la motivation pour la mettre en oeuvre.

En ce qui concerne WordPress, il y a toute la lecture du Codex, qui documente tout, et qui est structurée, débutant, développeurs, etc...

Intéressant. Je penche plutôt pour IPB à vrai dire, mais peut-être wordpress en vaut-il la peine. C'est un script plus simple qu'IPB, peut-être plus abordable pour commencer.

C'est ça la page ? https://codex.wordpress.org/fr:Accueil

Je voudrais de la doc en .pdf, si vous en connaissez... L'idée c'est vraiment ça : j'ouvre le fichier wordpress dans pspad, j'affiche la page index.php. Et voilà, qu'est-ce que je fais pour démonter le mécanisme, comprendre qu'est-ce qui fait quoi et où ça se trouve...

 

[Marie-Aude]

Intéressant. Je penche plutôt pour IPB à vrai dire, mais peut-être wordpress en vaut-il la peine. C'est un script plus simple qu'IPB, peut-être plus abordable pour commencer.

IPB est fait pour faire des forums, WordPress pour faire des sites. ça n'a rien à voir. Le premier est dédié à un type de site, le second généraliste - et pas bon sur les forums.

C'est ça la page ? https://codex.wordpress.org/fr:Accueil

C'est la page d'entrée. La version anglaise est nettement plus complète.

Je voudrais de la doc en .pdf, si vous en connaissez...

la doc WordPress est mise à jour en temps réel et elle représente des milliers de pages. Tu peux très bien générer tes pdf toi même.

L'idée c'est vraiment ça : j'ouvre le fichier wordpress dans pspad, j'affiche la page index.php. Et voilà, qu'est-ce que je fais pour démonter le mécanisme, comprendre qu'est-ce qui fait quoi et où ça se trouve...

Je traduis : je suis parachuté à un endroit au milieu des bois. J'essaye de comprendre où va chaque sentier, et chaque embranchement de sentier, pour bâtir le plan.

Il y a l'autre option : je monte en haut du belvédère, avec une carte, et je regarde. Autrement dit, je me prends une doc qui est structurée, faite pour faire comprendre les grands principes (The Loop, la hiérarchie des templates de modèles, comment faire un thème, comment faire un plugin, les guidelines pour bien coder dans wordpress, WP_Query et les Roles and Capabilities), une fois que j'ai avalé ça, c'est comme si j'avais vu ma carte, et compris l'architecture des chemins, je sais lesquels explorer en priorité.

Le fichier index.php ne fait rien, il renvoie juste à une série de fichiers qui choisissent d'en charger certains, ou de lancer l'installation. C'est intéressant à voir, mais pas primordial

Voir l'index.php d'un thème, c'est voir une série de fonctions WordPress, qui sont d'ailleurs documentées dans le Codex ET dans le code (wp-includes) mais franchement, partir des lignes de codes sans avoir la vue d'ensemble, c'est pas la bonne façon, amha. Surtout que chaque thème est codé "à sa façon".

 

[Alorsladaccord]

Intéressante métaphore, chère Marie-Aude.

Concernant IPB, ça ne sert pas qu'à faire des forums, ils ont un module IP.content intéressant pour créer des sites aussi. Mais c'est payant et plutôt cher, encore que leur support technique en vaille la peine. Mais ils ont pour désagréable habitude d'asservir leurs clients à leurs propres impératifs techniques ou supposés tels, tant et si bien que tous les trois ans on se retrouve avec un site à reconfigurer car ils ont changé tous leurs modules... La perfection n'est pas de ce monde.

J'ai installé wordpress en local, je vais voir ce que je peux faire avec tout ça... Mais alors pour faire simple : le tout premier fichier à consulter dans wordpress, c'est lequel au juste ?

 

[MikeR]

http://codex.wordpress.org/WordPress_Lessons
sinon,
http://codex.wordpress.org/The_Loop
http://codex.wordpress.org/The_Loop_in_Action

 

[Julia41]

Bonjour à tous,

Bon passons sur les "frameworks", je cherche simplement un plan classique pour organiser mes fichiers. Par exemple :
Index.php
-> include fonction.php puis + header.php + page.php + footer.php.
C'est tout ?

Mais en fait, j'ai une autre question : n'est-ce pas une erreur de coder son script à soi dans son coin ? J'ai fait comme ça la dernière fois et de tout mon travail (énorme : forum perso, admin, historique, zone mp, etc... etc...) il ne reste simplement rien du tout : que dalle, zéro.

Alors moi je suis un "gros dégueulasse" dans mon code, mais certains apprécient mes manières de coder, d'autres non.
Perso, mon index.php n'a qu'un seul include/require qui est le functions.php, lui ayant quasiment tout dedans (en require aussi).
Mon template est une classe :
echo $Template->Header('balise Title', 'include de JS', 'meta description', 'quelques autres params pour par exemple navbar true/false etc');
Ma page est le code de la page
le footer en classe aussi.

Cela me permet d'avoir un index.php (pour l'index ça peut être différent car accueil) avec :
include functions
function/class header
Direct mon contenu dès la ligne 4 du fichier (pouvant bien entendu utiliser des functions).
function/class footer

Ca a l'avantage de garder un code simple et de ne pas chercher dans 500 classes "il est où mon contenu" s'il était dans une DB SQL, c'est quel table au fait.

C'est pas le plus beau, mais ça a l'avantage de "quelqu'un arrive, il sait directement où est le code" (par exemple, tu développes pour un webmaster qui n'y connait pas trop grand chose en prog, il sera capable de modifier une faute d'orthographe, rajouter une fonction, assez simplement).

Attention, cette méthode ne fonctionne que pour certains type de sites hein

Donc n'est-ce pas plus judicieux de travailler sur un projet déjà existant (wordpress, dotclear, IPB...), de comprendre le fonctionnement général puis de coder les pluggins dont on a besoin ?
La réponse m'apparait être oui, bien entendu. Le problème c'est que c'est un gros gros boulot pour démonter les scripts en question, les analyser etc... Alors y'a-t'il des méthodes particulières pour ça ? Je veux dire, pour analyser et comprendre la structure des gros scripts tels que ceux-ci dessus.

Merci d'avance.

Oui et non, c'est par défaut lourd, car ça fait déjà tout. Si tu veux faire un blog, en effet un CMS fera largement l'affaire.
Par contre pour ma part, un blog peut se contenter de 3 tables si tu n'as pas de gestion d'utilisateurs (je ne vois plus beaucoup de blogs où on DOIT se créer un compte), la partie rédaction peut être codé par htpasswd/htaccess. Un blog simple n'a que : les contenus, les commentaires, et les tags.

Voilà pour un petit retour dans ma méthode, le soucis d'un gros CMS pourrait venir si tu as du traffic, c'est très vite très lourd.