8768 sujets

Développement web côté serveur, CMS

Trucs, astuces et bonnes pratiques en PHP

Pages :
(reprise du message précédent)

jmlapam a écrit :

Mais kezako pas HTML dans PHP ? en quoi c bonne pratique ? Pour la maintenance j'imagine?


C'est un des résultat de l'application du principe "Separation of concerns" (je ne connais pas la traduction). On peut aller plus loin en disant : pas de PHP dans les vues.

Là tu as un excellent article qui explique le "Separation of concerns" : http://aspiringcraftsman.com/2008/01/03/art-of-separation-of-concerns/

jmlapam a écrit :

Sinon perso je préfère include a require. Même perf alors qu'une bouze dans require te fout en l'air le script entier



Include ne présente aucun intéret. Personnellement j'utilise uniquement require (quand un fichier manque tu VEUX que ça provoque une erreur).

Modnar a écrit :

Je pense que c'est justement le but de require de remonter une erreur fatale et d'arrêter l'éxecution du script. Ça évite d'avoir un code qui s'exécute avec des données obsolètes. Smiley biggrin


Absolument.

Modnar a écrit :

Concernant l'absence de HTML dans le PHP, c'est pour séparer les couches (comme le disait jb_gfx plus haut). Par exemple, garder tout le code HTML pour les vues, dans le cas d'un projet MVC, et n'utiliser le PHP que pour afficher le contenu des variables.


Oui, le template (la vue) devrait ne contenir aucune logique et simplement servir à un bête affichage des données.

Modnar a écrit :

le <?= C'est une sorte de raccourci assez pratique. Par contre, il faudrait vérifier la compatibilité selon la version PHP, avec l'activation ou non des shorts open tags. Dans les dernières versions, il me semble que les shorts open tags sont désactivés par défaut, mais qu'on peut tout de même utiliser &lt;?= sans soucis... à confirmer. Smiley biggrin


En PHP 5.3 et moins <?= nécessite que short open tags soit activé, en PHP 5.4 ce n'est plus le cas (d'ailleurs les short open tags n'existent plus).

Su4p a écrit :

Autant pour moi :
http://php.net/manual/fr/control-structures.alternative-syntax.php

J'étais persuader que cette syntaxe était propre à un langage de template.


Oui c'est une syntaxe très pratique pour les templates car elle améliore largement leur lisibilité.

Su4p a écrit :

Avoir un et un seul point d'entré ! qui redirige vers les différents contrôleurs ou vers les différentes actions et vues à réaliser.


+1
Modifié par jb_gfx (14 Aug 2012 - 16:17)
L'opérateur ternaire j'aime bien aussi :
$eleve_admis = ($moyenne >= 15) ? true : false;
//Parce que je trouve ça joli.



Lothindil a écrit :

Ce que j'ai fait perso pour éviter la redondance (après, je sais pas ce que ça vaut), c'était un fichier inc.debut.php que j'inclus au départ de tous mes fichiers php

Il y a un contre-sens dans cette phrase.

Bref je ne vois pas l’intérêt de faire plusieurs point d'entrés, quand on peut en avoir qu'un.

De plus imaginons que qqn t'aide à développer, il cherche à modifier l'action "déplacer joueur".
Dans le cas d'un point d'entré unique :
1. La personne ouvre le fichier "aiguilleur" et trouve 2. le fichier/ l'objet concerné par cette action.

Dans le cas d'une application avec plusieurs point d'entré :
Le développeur va devoir 1.chercher sur quel fichier l'action est invoqué, 2. puis il devra chercher la ligne où il est indiqué le fichier appelé pour enfin 3. se rendre sur le fichier à modifier.
En règle générale je me suis rendu compte qu'avec cette approche tu te retrouves vite avec une dizaine de fichiers ouverts pour chercher à modifier une seule action.
Modifié par Su4p (14 Aug 2012 - 17:14)
Euh ça donne plutôt : le developpeur ouvre le fichier .doc de documentation, chercher "déplacer" ou "mouvement" ou "bouger" avec un simple ctrl+F. Il y apprend que cette action se gère sur le fichier mouvement.php et que la requête est générée sur le fichier inc.deplacement.php ^^

Puis il récupère le fichier qui contrôle le mouvement (mouvement.php) et le fichier qui génère la requête (inc.deplacement.php)...

Je dois vraiment avoir une technique d'organisation toute personnelle moi. Smiley ravi


Et oui, à partir de là, j'ai un "require_once("inc.debut.php");" dans tous les fichiers qui ne sont pas des fichiers servant à être inclus ou des fichiers de fonctions (reconnaissables : inc.xxxx.php et fct.xxxx.php)



Et sinon en code, ça ressemble à quoi votre fichier aiguilleur, et on l'utilise comment... Smiley biggol (ça peut s'avérer intéressant comme truc l'air de rien).



edit : et encore, c'est un ancien fichier mouvement que j'ai la flemme de renommer. Comme il s'agit d'un fichier sans retour d'affichage *sauf erreur/triche*, il devrait se nommer svr.mouvement.php pour "fichier de travail serveur" ^^
Modifié par Lothindil (14 Aug 2012 - 17:45)
Lothindil a écrit :
Et oui, à partir de là, j'ai un "require_once("inc.debut.php");" dans tous les fichiers qui ne sont pas des fichiers servant à être inclus ou des fichiers de fonctions (reconnaissables : inc.xxxx.php et fct.xxxx.php)


require_once c'est pas l'ami des performances, surtout si tu utilises un cache d'opcode comme APC.

Lothindil a écrit :

Et sinon en code, ça ressemble à quoi votre fichier aiguilleur, et on l'utilise comment... Smiley biggol (ça peut s'avérer intéressant comme truc l'air de rien).


Le Router se charge de convertir l'URL en action et de charger automatiquement le contrôleur correspondant (la classe) et d’exécuter l'action demandée (la méthode) avec les paramètres fournis.

Par exemple si je demande l'url monsite.com/article/show/un-super-article, le routeur parse l'url et il sait que je demande d’exécuter la méthode show de la classe Article avec le paramètre "un-super-article" (l'identifiant de l'article). Ainsi tout ce qui est instanciation des objets (Article) et appelle des méthodes est automatisé dans ton application et tu n'as plus jamais besoin de t'en soucier.

Bon c'est la forme la plus simple possible, après tu as des Routeurs avancés qui permettent d'avoir des url exactement de la forme que tu souhaites.
Modifié par jb_gfx (14 Aug 2012 - 19:42)
jb_gfx a écrit :
On peut aller plus loin en disant : pas de PHP dans les vues.

L'article est intéressant mais à mon avis pas complètement à jour, parcequ'il y a des erreurs dès le début :
"can you give me just one recent change in the PHP language which enhanced PHP as a template language? I cannot think of one.".
Moi j'ai un changement qui date de php 5.4 et qui est très clairement destiné à améliorer php en tant que moteur de template : l'ajout de la syntaxe <?=$foo?> pour faire un echo indépendamment des shorttags. Et du coup son premier argument tombe un peu à l'eau quand il reproche à <?php echo $var ?> de ne pas être assez concis.
Pour le reste je suis plutôt d'accord. Je continue à utiliser php pour faire les pages html à coups de <?= et de for(): / endfor, mais j'aime bien Twig et je m'en servirai probablement à l'occasion.


Sinon une "bonne pratique" qui peut paraitre évidente mais n'est pas encore appliquée par tout le monde : Utilisez un IDE !
Il y en a plein qui fonctionnent bien avec php et ça permet de:
-gagner du temps grâce à la complétion et à l'affichage de la documentation (ça évite de farfouiller sur php.net, jquery.com etc.), et la refactorisation.
-Eviter les erreurs d'inattention : toutes les erreurs de syntaxes sont immédiatement repérées, ainsi que la plupart des syntaxes dangereuses comme if($foo = 'bar'), l'utilisation d'une variable non assignée, ou la déclaration d'une variable non utilisée.
-Inciter à coder proprement : Quand l'IDE utilise automatiquement les commentaires phpdoc pour compléter et afficher la doc des fonctions/classes, on est d'avantage tenté d'écrire la documentation en question ^^
-Débugger plus facilement avec Xdebug ou PHPUnit.
-Avoir un gestionnaire de version local même si on utilise pas SVN ou git ou autres.
Modifié par BlueScreenJunky (15 Aug 2012 - 12:21)
BlueScreenJunky a écrit :

Utilisez un IDE !


Clairement, un IDE fait gagner un temps fou. Je ne comprends pas les gens qui bossent sur un projet et qui utilisent Notepad++ ou le très surévalué SublimeText.

T'as oublié : écriture automatique des getters et setters, macros avancées, etc. Smiley murf
Modifié par jb_gfx (15 Aug 2012 - 15:17)
Personnellement je suis sur Komodo,
pas de raison particulière je suis passé de notepad++ à komodo donc c'était le jour et la nuit.

Je suis curieux de savoir quels sont vos IDE et pourquoi celui la plutôt qu'un autre ?
Modifié par Su4p (15 Aug 2012 - 20:45)
KDevelop, pars qu’il est bien intégrer au bureau KDE et qu'il affiche chaque variable avec une couleur différente, ce qui est jolie et pratique ^^. Puis il s'ouvre rapidement, un peu prés 4 secondes.
Je me suis également fait quelques plugins et beaucoup de commandes (sorte d'extension pour manipuler le contenu du fichier ouvert) dont j'ai maintenant du mal à me passer.

Ça fait 2 ans que je ne fait plus de projet php, je l'utilise pour du C/C++ mais à l'époque KDevelop planté parfois avec php et le debug avec xDebug n'existais plus… Faut dire aussi que le logiciel était en plein changement pour permettre le support de tous langages via la création de plugin et le support php était récent.
Depuis le temps je pense que c'est corriger et il existe un plugin nommer kdevelop-xdebug.

Après c'est un IDE comme les autres avec plus ou moins de chose. Un truc que je trouvais sympa est qu'il listé les types possible d'une variable. Par exemple quand on change le type dans une condition. Du coup l'auto-complétion affiche les méthodes des 2 types. Je ne sais pas comment ce comporte les autres IDE dans ce cas.

Je pense qu'il fonctionne sur Windows et Mac Os mais ça demande beaucoup de dépendances sur les lib kde.
Modifié par jo_link_noir (15 Aug 2012 - 23:19)
Su4p a écrit :

Je suis curieux de savoir quels sont vos IDE et pourquoi celui la plutôt qu'un autre ?


Net beans : disponible sur tous les OS, puissant, relativement stable et gratuit.
Modifié par jb_gfx (16 Aug 2012 - 19:25)
Netbeans aussi pour ma part. PHPStorm a l'air peut être un peu mieux pour certaines choses, mais payant. Sinon en gratuit Aptana a l'air correct.
(je crois que les 3 sont multi plate-forme)

Pour revenir sur les bonnes pratiques (enfin là c'est plutôt les mauvaises pratiques qui m'énervent) : ça aide beaucoup de ne pas utiliser les noms de variables cryptiques. Aujourd'hui encore je suis tombé sur un script avec des $data, des $array et des $i, et quand on repasse derrière c'est particulièrement pénible.
Je trouve que c'est particulièrement important dans les paramètres des fonctions/méthodes : Ce n'est pas parcequ'une fonction ne prend qu'un paramètre qu'il est inutile de le nommer correctement. Quand on reprend le script 6 mois après on a pas toujours envie de relire 40 lignes de codes pour se retrouver que le $data attendu c'était la date au format iso.
Au fait, j'ai lu sur différents sites deux grandes manières de gérer les connexions sql :

- ouverture au début du fichier (partie récupération de données), fermeture juste avant l'affichage.

- ouverture et fermeture de la connexion à chaque utilisation de la base de données.

Laquelle est la meilleure ? La plus économique pour le serveur ?
Modifié par Lothindil (17 Aug 2012 - 13:37)
Ouvrir quand besoin ce fait, fermé quand besoin ce fait plus. Et une seul fois dans la "page".
En général à l'affichage tu as toutes les données, alors fermé la connexion ne pose pas de problème.
Lothindil a écrit :
ouverture et fermeture de la connexion à chaque utilisation de la base de données.


Surtout pas.
jb_gfx a écrit :


Surtout pas.


+1

connexion persistante FTW Smiley langue

Très bien ce topic en tout cas jb.

Certains vont surement me conspuer mais voici un opérateur bien sympa pour la concision du code, le ternaire:


$test = true;

// Au lieu de :

if($test)
{
  $str = 'ok';
}
else
{
  $str = 'pas ok';
}

// mettre:

$str = ( $test ? 'ok' : 'pas ok' );

// Format : ( CONDITION ? VALEUR SI VRAI : VALEUR SI FAUX )


Certains diront que c'est du chinois, moi je dit de c'est 10% de code en moins Smiley langue

a écrit :
L'opérateur ternaire j'aime bien aussi :

$eleve_admis = ($moyenne >= 15) ? true : false;

//Parce que je trouve ça joli.


Aucun interet dans ce cas:


$eleve_admis = ($moyenne >= 15)

Une autre chose qui parait évidente quand on connait mais qui peut être utile, inverser le switch:


$arr = array('lol', 'blabla');

switch(true)
{
  case in_array('lol', $arr ) :
    //faire quelque chose
    break;
  case 1==1:
    // faire autrechose
    break;
}

Modifié par JJK801 (22 Aug 2012 - 14:28)
Salut à tous,

très bon sujet que celui ci.

alors je ne sais pas si ce sont des bonnes pratique mais je les vois et utilisent régulièrement

- l'accolade

//exemple
if($a == $b)
   echo "bouh";

//autre exemple
for($i=0; $i<$j; $i++)
   if($i == $a)
      if($a==$b)
         echo "bouh";


les accolade ne sont pas nécessaire si il n'y a qu'une ligne en dessous et cet effet est cumulable


- le ";"


<?php echo "bouh" ?>

il n'est pas nécessaire si il précède une fermeture ?>
Pour les accolades, y a 2 sons de cloche, perso je préfère les mettre au cas ou je doit rajouter des lignes par la suite.

Pour le point virgule c'est source d'erreur pour la suite Smiley cligne
Je préfère aussi ajouter systématiquement les accolades.

JJK801 a écrit :

Très bien ce topic en tout cas jb.


J’espérais que Julien Royer et paolo participeraient. Smiley ohwell
Modifié par jb_gfx (22 Aug 2012 - 18:23)
Accolades, j'utilise toujours, je trouve ça plus clair, surtout dans le cas où c'est cumulatif.

point-virgule, j'utilise toujours aussi, c'est une source d'erreur classique...


Une autre, plus général :
- des noms de fichiers clairs, s'il vous plaît... On évite les "actions1.php", "actions2.php",... c'est illisible...

Idem pour les noms d'images : texture1.png, texture2.png, texture3.png ou encore msg1.png; msg2.png; msg3.png c'est pas clair Smiley biggol



Ah oui, et sauf obligation, éviter les $_REQUEST pour récupérer les informations issues d'un formulaire.

Et tant qu'on y est, oubliez un peu les $HTTP_GET_VARS et autres $HTTP_SESSION_VARS; c'est obsolète... Smiley eek
Pages :
Sujet clos
Aller à