Conseils d'amélioration d'un code PHP

a marqué ce sujet comme résolu.

Bonsoir ! :)

J’ai développé, un peu vite fait il faut le dire, un début de site e-commerce sans prétention (je compte pas forcément le terminer).

J’aimerais avoir un maximum de conseils afin d’avoir le code le plus parfait possible. Par contre, je ne souhaite pas de réponses toute faites (en gros, pas de bouts de code), mais simplement des indications, des astuces, pourquoi pas des liens vers des écrits pour en apprendre un peu plus.

J’ai tendance à faire des codes pas très optimisés, des codes à rallonge aussi. J’aimerais corriger cela.

Concernant l’architecture des dossiers, elle est très loin d’être optimale. Je ne souhaite cependant pas la modifier, bien qu’il faudrait le faire absolument. La raison est assez simple, cette organisation proviens des cours que j’ai pu suivre, et j’était curieux de savoir comment je pouvais m’en sortir sur un projet plus ou moins gros avec. D’où le fait que je n’utilise aucun framework, et je ne me m’autorise pas à utiliser des packages composer (ça, ce sera plus tard).

Je vous donne donc le lien du dépôt : https://github.com/FougereBle/ecommerce-test

Contrairement à mon habitude, je n’ai pas du tout pensé "Responsive" dès le départ pour le design. Le but ici n’est pas d’avoir une application prête à déployer et être utilisée, elle sera même supprimée après. C’est juste le côté back qui m’intéresse, je ne me suis vraiment pas occupé de la partie front.

Afin que vous puissiez vous y retrouver au mieux, voici comment le code est organisé :

  • Il utilise une architecture MVC… enfin, d’après mes cours… quoi que c’est pas tout à fait faux.
  • Le dossier class correspond aux models, le dossier process aux controllers et les fichiers à la racine, aux vues.
  • Le dossier includes comprend les deux parties d’un template (header et footer), la connexion à la base de données et un fichier qui comprend certaines fonctions utiles.
  • Les models sont séparés en deux classes : Un Model, représentant une ligne de la table, et un ModelManager qui sert à effectuer les opérations en base (les requêtes SQL quoi).

Voilà. Je remercie d’avance celles et ceux qui prendront le temps de lire le code et de me faire des retours. :)

+0 -0

Salut !

C’est un petit projet, mais la version actuelle du code est propre, bravo !
J’ai toutefois une question : la structure de la base de données, quelle est-elle ? Je trouve un peu dommage qu’on doive aller regarder les requêtes pour la voir. Ce qui fait que je n’ai pas de quoi la créer telle que tu l’as voulue (types de champs exacts, tailles de ceux-ci notamment).

Vu que tu le demandes, je vais me permettre de te mentionner quelques points mineurs que je vois, dans l’ordre d’importance.

Première chose : documente ton projet, étant donné que c’est quelque chose que tu as crée de A à Z. Les explications que tu nous donnes ici sur la structure des dossiers, elles pourraient être versionnées avec ton projet. Je serais assez tenté de créer un fichier dossier doc, quitte à mettre le lien vers ce dossier dans un fichier readme à la racine du projet. Ce fichier readme explique ce qu’est le projet, dans /doc tu mettrais des informations plus techniques.

Seconde chose (même si là c’est un peu l’hôpital qui se fout de la charité venant de moi) : commente ton code  :D   :ange:
J’ai malheureusement un exemple très récent où ça m’aurait été bien pratique : je sors d’une période où, sur trois mois, j’ai implémenté une foule très dense de features plus ou moins complexes sur divers projets. Cette semaine, j’ai dû regarder pour adapter l’une d’entre elles à de nouveaux impératifs. Il m’a fallu une journée pour me remettre dans le code que j’ai pourtant écrit il n’y a que trois mois.

Troisième chose, qui peut paraître de la tentative de copuler avec un insecte : pense à regarder du côté du formatage du code. En PHP, il y a une manière de faire qui s’installe, ce sont les PHP Standard Recommendations. Actuellement, pour le style de codage, c’est PSR-12.
Comme dit dans l’abréviation, ce sont des recommandations. J’avoue que parmi celles-ci, j’ai personnellement de la peine avec l’espace entre un ! et la variable quand je fais une négation… mais là à relire je trouve la documentation floue sur ce point précis.

+0 -0

Merci pour ta réponse. :) Je vais essayer de répondre point par point.

C’est un petit projet, mais la version actuelle du code est propre, bravo !

Déjà, merci ! Sincèrement, j’avais peur que mon code ne soit pas propre. Mais je suis sûr qu’il est encore possible de faire quelque chose. Je cherche toujours à ce que mon code soit le plus parfait possible, même si j’ai lu une phrase il n’y à pas longtemps qui disait : Je sais plus ce que ça disais :D Mais en gros qu’il fallait pas chercher toujours à optimiser, car on passe plus de temps dessus qu’à travailler sur le projet.

J’ai toutefois une question : la structure de la base de données, quelle est-elle ?

La base de données… oups ? En effet, je ne l’ai pas inclus. Penses-tu qu’une copie d’un fichier .sql est suffisant, où il y à une autre façon de procéder qui serait mieux ? J’avoue ne pas vraiment connaître comment ça se passe niveau partage de base de données.

Mais bon, ça risque de faire peur. Je crois que j’ai vraiment fait ça à la "je m’en fou" et j’ai tout mis tout les VARCHAR en 255… :D

Première chose : documente ton projet

Ah, cette bonne vielle doc. Idem, je n’ai pas pensé à l’inclure… ni même à l’écrire (je sais même pas comment on écrit une bonne documentation). Tu pensais à un texte qui ressemblerais à ce que j’ai écrit dans mon premier post (le passage sur l’explication de l’application) ou une documentation générée via les commentaires fait exprès pour, style phpDoc ?

Seconde chose (même si là c’est un peu l’hôpital qui se fout de la charité venant de moi) : commente ton code

Je m’y attendais. :D Oui, j’ai rien commenté. Déjà, parce que je n’ai pas pris l’habitude de le faire (et donc ce n’est pas automatique chez moi), mais aussi parce que comme je ne l’ai jamais fait, je ne sais pas comment on fait. Enfin plutôt, comment commenter au mieux son code.

Mais c’est bien que tu me dise ça, car c’est en effet un point que je dois améliorer. C’est aussi le but de ce sujet, m’améliorer. Je vais donc voir si il existe un tutoriel ou une sorte de guide pour ça. Si vous en avez un à me conseiller, je suis preneur.

Troisième chose, qui peut paraître de la tentative de copuler avec un insecte : pense à regarder du côté du formatage du code.

Tu parle du fait que je fasse ça :

function foo() {
    echo 'bar';
}

et pas :

function foo()
{
    echo 'bar';
}

?

Si tu parle aussi des " et ', je sais pas du tout ce que j’ai fait dans mon code. J’ai tout mélanger. :D Il faut que je corrige, mais normalement je met toujours des single quotes pour le PHP (et je concatène toujours comme ceci 'foo ' . $bar et pas "foo $bar").

Mais merci en tout cas pour ta réponse complète !

+0 -0

Salut,

Je trouve que c’est un exercice de style intéressant de faire une code review. Surtout quand c’est dans un cadre non professionnel et que l’auteur du code cherche clairement à s’améliorer. Voici donc mes retours :

L’organisation des fichiers :
Il y a des choses qui sont complètement mélangées, et c’est le bordel. Un dossier includes à la racine qui contient du HTML et des fonctions utilitaires… Ce n’est pas logique. Pire, des vues directement à la racine du projet. Au passage, il serait intéressant de différencier les vues des autres fichiers. Quand je vois un fichier product.php, je ne me dis pas "tiens, ça va être une vue". Mettre tes vues dans un dossier à part et les différencier serait pas mal.

Les conventions de nommage des fichiers :
Tu as des fichiers en camelCase et d’autres en snake_case. Choisis l’un des deux et tiens toi à ce choix.

La doc, la doc, la doc :
Pour moi, la PHPDoc est indispensable à tous les projets PHP ! Si je prends par exemple ce code, impossible depuis un autre fichier de savoir ce que je dois passer. Et quand en plus un array est attendu (ce qui est une très très très mauvaise pratique), là ça devient vraiment difficile.

Les array en arguments :
Comme je le disais, c’est une très mauvaise pratique.

public function __construct($data) {
        $this->setId($data['id'] ?? 0);
        $this->setFirstName($data['firstname'] ?? '');
        $this->setLastName($data['lastname'] ?? '');
        $this->setProductsFromJson($data['products'] ?? '[]');
        $this->setPrice($data['price'] ?? 0);
        $this->setCreatedAt($data['created_at'] ?? '');
    }

Ce n’est pas clair, on ne sait pas ce qu’on doit envoyer exactement, on peut faire une erreur de typo, etc. En plus là tu ne vérifies même pas l’existence des clés présentes. Si la clé created_at n’existe pas par exemple, ton code plante ; or a priori, pour cette valeur, on pourrait mettre automatiquement un new \DateTime();.
Ce qui nous amène au point suivant.

Les arguments et le typage :
Je vais partir du principe que tu tournes sur PHP 7.2. Pourquoi ? Car depuis cette version, il est possible de typer correctement les arguments attendus par une méthode. En plus d’éviter des erreurs, c’est une indication de ce qui est exactement attendu. Ainsi l’exemple précédent devient ceci :

public function __construct(int $id = 0, string $firstname = null, string $lastname = null, array $products = [], float $price = 0, \DateTime $createdAt = null)
{
        // Code modifié
}

Ce qui reste, pour moi, toujours une mauvaise chose. On voit très bien ici que les arguments sont optionnels. À partir de là, le __construct() ne sert à rien, autant passer par les setters appropriés dans le code qui appelle cette classe.

Découpe ton code :
Quand je vois un fichier fourre-tout comme celui-ci, ça me fait peur. Outre le fait que ce ne soit pas un objet, des fonctions n’ayant rien à voir cohabitent entre elles. Et ça c’est mal. Aujourd’hui tu as peu de fonctions, il est relativement facile de s’y retrouver. Mais demain, quand ton fichier contiendra 100 fonctions, ce sera beaucoup plus compliqué de s’y retrouver. Et là deux solutions : tu continues à tout entasser là-dedans pour finir par avoir un fichier monstrueux (au sens propre et figuré) et lourd à charger ; ou alorstu crées plusieurs fichiers thématiques (un fichier qui gère les sessions, un autres les messages flash, etc) en galérant à modifier et ajouter des require dans ton code. Alors qu’en découpant dès le départ ton code, aucun soucis.

La BDD :
C’est une chose que négligent la plupart de ceux qui débutent (et même certains qui ne débutent plus), et c’est un tort. Ton code aura beau être le plus propre et optimisé possible, si ta BDD est bancale, ton site sera bancal.

Sans connaître ta pratique du langage, c’est difficile de donner un avis général. Si tu fais du PHP depuis 5 ans par exemple, ce n’est pas terrible. En revanche si tu débutes, c’est plutôt bien.
Quelle est ta prochaine étape ? Tu parles d’utiliser des packages tierces. Tu veux continuer à améliorer ce projet, apprendre un framework, créer le tien (sans aucune prétention évidemment, mais c’est quelque chose de très formateur, même quelque chose de simple) ?

+0 -0

Merci pour cette réponse complète. Je vais essayer de reprendre chaque points comme au dessus. :)

Il y a des choses qui sont complètement mélangées, et c’est le bordel.

Ah, ça, carrément ! :D Comme je l’ai dit dans mon post initial, cette organisation n’est pas bonne. Je ne souhaite pas la changer pour les raisons énoncées plus haut : C’est une formation (un peu pourrie) que j’ai suivie, et ils nous apprenne à coder avec cette organisation… que je trouve bordélique. Effectivement c’est à revoir, mais je souhaite continuer comme ça car je suis curieux de savoir comment on peu s’en sortir avec sur un projet un peu conséquent, raison pour laquelle j’ai choisis un site e-commerce.

Les conventions de nommage des fichiers : Tu as des fichiers en camelCase et d’autres en snake_case. Choisis l’un des deux et tiens toi à ce choix.

Alors là c’est ma faute. :p J’ai pris pour habitude (et donc merci pour cette remarque, c’est une nouvelle fois un point que je dois améliorer) de nommer mes fichiers en CamelCase pour les classes, et les autre fichiers en snake case. En vrai, je je trouve étrange de voir tout les fichiers en CamelCase. Par exemple, si tu prend un projet Laravel, les vues sont en snake case et les entité ou controller en CamelCase (donc les fichiers étant des classes). Quelles nommage dois-je utiliser selon toi ?

Pour moi, la PHPDoc est indispensable à tous les projets PHP ! Si je prends par exemple ce code, impossible depuis un autre fichier de savoir ce que je dois passer. Et quand en plus un array est attendu (ce qui est une très très très mauvaise pratique), là ça devient vraiment difficile.

Merci ! J’attendais cette remarque. :D

Alors pour expliquer un peu pourquoi ça : Comme je l’ai dit un peu plus haut, j’ai suivis une formation qui est tout sauf excellente. Devine quoi ? Oui, voilà comment ils nous apprennent à coder dans les cours.

J’ai aussi pensé que c’était une erreur de faire comme ça, pour les même raisons que tu énonce. Cependant, je me suis dit : Ok, peut être que je me trompe ?

Pour en être sûr, j’ai décidé de laisser comme ça dans ce projet, en espérant avoir une remarque dessus, ce qui est le cas, et donc ça confirme mes pensées.

D’ailleurs, dans mes autres projets (sauf quand je rejoins une équipe, auquel cas j’essaye de suivre ce qui à déjà été mis en place), je met le type de la variable dans les paramètres et je ne passe pas de tableau (sauf dans certain cas).

Ce n’est pas clair, on ne sait pas ce qu’on doit envoyer exactement, on peut faire une erreur de typo, etc. En plus là tu ne vérifies même pas l’existence des clés présentes.

Alors en fait si, je vérifie. $arg['foo'] ?? 'bar' par exemple, indique de passer la variable $arg['foo'] si elle existe, sinon ça enverra bar. C’est la même chose que isset($arg['foo']) ? $arg['foo'] : 'bar'.

Je vais partir du principe que tu tournes sur PHP 7.2. Pourquoi ? Car depuis cette version, il est possible de typer correctement les arguments attendus par une méthode. En plus d’éviter des erreurs, c’est une indication de ce qui est exactement attendu. Ainsi l’exemple précédent devient ceci :

Cf. un peu plus haut.

Découpe ton code : Quand je vois un fichier fourre-tout comme celui-ci, ça me fait peur.

Là par contre, c’est en effet une amélioration que je dois faire. Je ne savais pas trop si je devais tout mettre dedans et faire comme un fichier "helper", où séparer. J’ai peur qu’en séparant, je me retrouve avec 1000 fichiers (j’exagère, ok :p ) qui ne contienne qu’une ou deux fonctions.

Donc, avec ta remarque, je pense que je vais créer un dossier "helpers" et y mettre plusieurs fichiers découpés. Penses-tu cependant qu’il soit mieux d’inclure tout ces fichiers partout (donc dans le top.php), ou les inclure là où j’en ai besoin ? Je pencherais plus pour la seconde option. Mais comme le but et de m’améliorer, j’attend tout de même ta réponse (pour ne pas prendre une mauvaise habitude).

C’est une chose que négligent la plupart de ceux qui débutent (et même certains qui ne débutent plus), et c’est un tort. Ton code aura beau être le plus propre et optimisé possible, si ta BDD est bancale, ton site sera bancal.

Il faut vraiment que j’apprenne à utiliser une base de données. C’est quelque chose que j’ai toujours négligé. Je met souvent des VARCHAR 255, aucune clé étrangère (je crois que c’est important lors d’une relation), etc.

Donc merci encore pour ta réponse. :) Ca fait des points à améliorer, et ça à aussi confirmer certaines pensées que j’avais.

D’ailleurs, pour m’y retrouver un peu plus et reprendre chaque points, je vais me créer un petit document listant les choses que je dois revoir. :)

Dans tout les cas, c’est très gentil à vous d’avoir pris du temps pour lire mon code et me faire des réponses complètes. Je vous remercie encore une fois. :)

Je continue ce projet ce soir en incluant les améliorations, et je vais par la même occasion faire un peu de lecture sur certain sujets.

+0 -0

C’est une formation (un peu pourrie) que j’ai suivie, et ils nous apprenne à coder avec cette organisation… que je trouve bordélique. Effectivement c’est à revoir, mais je souhaite continuer comme ça car je suis curieux de savoir comment on peu s’en sortir avec sur un projet un peu conséquent

FougereBle

Attention justement à ne pas trop t’habituer à cette organisation, changer peut être difficile. Mais je comprends le principe. Maintenant je te le dis, ça ne peut rien donner de bon de garder cette organisation sur un projet conséquent. Ne serait-ce que parce que tes vues ne sont pas dans un dossier. Là tu as 2 ou 3, mais sur un site ecommerce, tu en as normalement des centaines !

Alors là c’est ma faute. :p J’ai pris pour habitude (et donc merci pour cette remarque, c’est une nouvelle fois un point que je dois améliorer) de nommer mes fichiers en CamelCase pour les classes, et les autre fichiers en snake case. En vrai, je je trouve étrange de voir tout les fichiers en CamelCase. Par exemple, si tu prend un projet Laravel, les vues sont en snake case et les entité ou controller en CamelCase (donc les fichiers étant des classes). Quelles nommage dois-je utiliser selon toi ?

FougereBle

Étant développeur Symfony, ma réponse ne sera pas objective. Les fichiers PHP sont en CamelCase, les templates en snake_case (encore que c’est moins normalisé pour ces derniers). Du coup c’est ce que je fais. Mais je devais faire un projet comme ça, sans framework, je mettrais en CamelCase avec des distinctions dans le nom des classes si nécessaire (comme Symfony en fait :p ).

Alors pour expliquer un peu pourquoi ça : Comme je l’ai dit un peu plus haut, j’ai suivis une formation qui est tout sauf excellente. Devine quoi ? Oui, voilà comment ils nous apprennent à coder dans les cours.

FougereBle

C’est pour ça qu’il faut prendre le pli de suite. Je me suis battu dans ma boîte pour que les autres dev mettent systématiquement la PHPDoc, parce qu’au final ça fait gagner un temps fou (et que phpStorm l’écrit tout seul, en plus).

Donc, avec ta remarque, je pense que je vais créer un dossier "helpers" et y mettre plusieurs fichiers découpés. Penses-tu cependant qu’il soit mieux d’inclure tout ces fichiers partout (donc dans le top.php), ou les inclure là où j’en ai besoin ?

FougereBle

Oui clairemement il faut charger uniquement ce dont tu as besoin. Le mieux restant cependant l’autoload, mais on est sur le cran au dessus par raport à du chargement "manuel".

Il faut vraiment que j’apprenne à utiliser une base de données. C’est quelque chose que j’ai toujours négligé. Je met souvent des VARCHAR 255, aucune clé étrangère (je crois que c’est important lors d’une relation), etc.

FougereBle

Alors autant les varchar en 255 c’est pas top mais "à la rigueur ça passe". En revanche ne pas utiliser de clés étrangères devrait être passible de poursuites judiciaires. Enfin dans un SGBDR classique. Si tu utilises MySQL, je te conseille MySQL Workbench, qui est assez facile à utiliser, qui te permet d’avoir un diagramme de ta BDD, et qui te construit le SQL pour créer les tables.

Bon courage pour la suite. :)

+0 -0

Merci encore une fois par ta réponse. :)

J’ai pas encore retouché à mon code (j’ai pas eu beaucoup de temps). Mais par contre, j’ai pu y réfléchir un peu.

D’un côté, de vous demande de l’aide pour améliorer mon code mais de l’autre… j’essaye de garder les quelques règles que je me suis fixé, règles permettant de tester ma formation.

C’est pas incompatible, mais maintenant que j’ai une idée plus précise de ma formation (plutôt, une confirmation de ce que je pensais), je me demande si c’est toujours utile de continuer à respecter ces règles (notamment sur l’architecture du projet).

Je pense que cela peut m’empêcher d’appliquer certaines astuces, et au final, mon but principal (l’amélioration de mon code) ne sera pas atteint jusqu’au bout.

Donc, je pense que je vais aussi revoir toute l’architecture des dossiers, et pourquoi pas faire un système de routing (ce sera mieux que 1 fichier => 1 page) et ajouter un moteur de template comme Twig. Je ferais ça dans un second temps, je vais d’abord améliorer ce qu’il y a à améliorer avant.

Vous en pensez quoi ?

+0 -0

Là c’est à toi de voir. Ça dépend aussi de ta formation. Si un projet est attendu en fin de formation, avec une structure particulière, autant rester là dessus et repartir sur autre chose quand la formation est terminée.

Après il y a des choses qui peuvent néanmoins être faites, comme la PHPDoc, le respect des PSR ou le découpage du code.

Même si selon moi, le mieux est d’essayer de faire le mieux possible dès le départ. Pour moi un bon code n’est pas uniquement un code qui fonctionne correctement ; c’est aussi un code élégant (dans sa présentation) et structuré.

+0 -0

J’ai terminé ma formation depuis un moment, donc je n’ai rien à rendre. C’est pour ça que je me suis posé la question.

Au final, j’ai décider de coder ça proprement.

J’ai donc commencé à changer la structure des dossiers. Pour ceux que ça intéresse, vous pouvez retrouver le projet dans son état actuel (c’est à dire pas fini, un mélange de la nouvelle structure et de l’ancienne) sur la branche dev du dépôt.

J’en ai profiter pour ajouter un router (j’ai choisis AltoRouter), de l’autoloading et ajouter des namespaces.

Ça me paraît déjà plus propre comme ça, même si certaines choses sont encore en chantier. D’ailleurs, il n’est plus possible de passer une commande dans cette version car je n’ai pas encore terminé ça.

Je ne sais pas si ça vaut le coup que vous me donniez votre avis sur la nouvelle version maintenant, car ce n’est pas finis et ça va encore un peu changer (par exemple, je vais virer ce fichier functions.php).

Edit : J’ai mis à jour la branche dev, j’ai simplement appliqué un peu plus le PSR-12 et ajouté des commentaires, de la documentation et un système de migration (pour le moment juste une seule table). Le système de migration me permet de ne pas avoir à partager un fichier .sql. Un simple vendor/bin/phinx migrate suffira à créer la base de données. :)

Par contre, j’ai trouvé un autre point que je dois améliorer, et pas qu’un peu : Mon anglais. :D En écrivant les commentaires, je me suis dit "Ok, ce que j’écrit là, à mon avis ça veut rien dire". Du coup j’ai hésité à les écrire en français, et même si c’est une mauvaise pratique, il vaut mieux que certaines personnes les comprennent (les francophones) plutôt que personne. Des avis dessus ?

+0 -0

J’ai un petit peu travaillé sur mon code et j’ai plutôt bien avancé. Tout se passe sur la branche dev du dépôt github.

Je remet ici mon édition du message plus haut, au cas où :

Edit : J’ai mis à jour la branche dev, j’ai simplement appliqué un peu plus le PSR-12 et ajouté des commentaires, de la documentation et un système de migration (pour le moment juste une seule table). Le système de migration me permet de ne pas avoir à partager un fichier .sql. Un simple vendor/bin/phinx migrate suffira à créer la base de données. :)

Par contre, j’ai trouvé un autre point que je dois améliorer, et pas qu’un peu : Mon anglais. :D En écrivant les commentaires, je me suis dit "Ok, ce que j’écrit là, à mon avis ça veut rien dire". Du coup j’ai hésité à les écrire en français, et même si c’est une mauvaise pratique, il vaut mieux que certaines personnes les comprennent (les francophones) plutôt que personne. Des avis dessus ?

J’ai donc rajouté Twig, ce qui permet de bien séparer le PHP de la vue.

Cependant, il y à certains points où je ne suis pas satisfait et j’ai besoin de votre aide.

Problème 1

Dans le fichier BaseController.php, j’ai une fonction render qui se charge d’afficher le template twig. Mais c’est là aussi que j’ajoute toutes les fonctions et variables globales pour Twig.

Pour le moment je n’en ai pas beaucoup, donc ça va. Mais je suis certain que ça peut être amélioré et mieux organisé.

Problème 2

Mon fichier index.php ne me conviens pas tout à fait. Il fait un peu tout et n’importe quoi, ce n’est pas structuré. Là aussi, je suis certain que l’on peut y apporter des modifications. Une chose que je n’aime pas trop, c’est les lignes 44 à 66. Je fait deux fois la même action pour gérer les deux cas possible : Le site est en production, et dois afficher le template errorXXX en cas d’erreur, sinon il ne doit rien afficher (et dans ce cas, c’est Whoups qui prend le relais). Je n’ai pas trouvé le moyen de faire une condition sur un catch (c’est impossible il me semble).

Problème 3

J’affiche le panier du visiteur dans toutes mes pages (dans le fichier layout.html.twig). Afin de pouvoir accéder au panier n’importe où, j’ai ajouté une variable globale cart dans Twig (dans le fichier BaseController.php). Encore une fois, on doit pouvoir faire plus propre. Ce qui me dérange là dedans, c’est que ce controller de base n’a pas à faire ça.

Un problème lié avec ça, c’est que je n’ai pas vraiment de moyen de gérer tout ça. J’ai un controller CartController qui fait des actions sur le panier, et j’ai aussi un helper Cart pour récupérer le panier… je pense qu’il est possible de réunir tout ceci.

D’ailleurs, je viens de remarquer que je pourrait utiliser mon helper Cart à la ligne 28 de mon CartController.

En plus de ces trois questions, je suis toujours ouvert aux autres remarques concernant le reste de mon code. :) Il y à eu pas mal de changements.

J’en ai profité pour ajouter un Readme qui explique comment installer le projet chez vous. Je n’ai pas testé, mais ça devrait fonctionner. :p

Merci encore !

Edit : Un petit lien direct vers la branche en question : https://github.com/FougereBle/ecommerce-test/tree/dev

+0 -0

Donc, avec ta remarque, je pense que je vais créer un dossier "helpers" et y mettre plusieurs fichiers découpés. Penses-tu cependant qu’il soit mieux d’inclure tout ces fichiers partout (donc dans le top.php), ou les inclure là où j’en ai besoin ?

FougereBle

Oui clairemement il faut charger uniquement ce dont tu as besoin. Le mieux restant cependant l’autoload, mais on est sur le cran au dessus par raport à du chargement "manuel".

Bon courage pour la suite. :)

John

Bonjour,

Je me permet de rebondir sur ce commentaire. Personnellement je fais aussi un fichier PHP avec toutes mes fonctions que j’utilise. Il faudrait donc faire un fichier par fonction ?

+0 -0

Bonjour,

Cela dépend du projet. Si c’est un petit site avec 3 pages et 5 fonctions, tout peut être mis dans un seul fichier. Si c’est un site avec 50 pages et 100 fonctions, il vaut mieux avoir plusieurs fichiers, chacun traitant d’un type de chose (1 gérant la BDD, 1 permettant de faire des calculs mathématiques, 1 permettant de faire des appels à une API, etc.). Sans ça on se retrouve avec un fichier de plusieurs centaines voire milliers de lignes.

Premièrement, c’est moins lourd à charger, mais c’est surtout beaucoup plus simple de s’y retrouver en tant que développeur. Si je cherche une fonction qui permet de récupérer des données d’une API, rien qu’en regardant le nom des fichiers, je devrais savoir dans lequel cela se trouve. Et le cas échéant, ne pas avoir à trouver mon aiguille dans ma botte de foin.

Après ce n’est pas une vérité absolue, ceci est mon avis. Mais j’ai tendance à penser qu’un projet bien rangé est plus facilement maintenable.

+2 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte