6 août 2009

Les 5 commandements du développeur PHP

Les 5 commandements du développeur PHPSi l’on devait citer 5 règles de bonnes pratiques qu’un développeur PHP professionnel devrait s’appliquer à lui-même, quelles seraient-elle ?

I. Toutes les erreurs lors du développement tu afficheras.

error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', true);

Ces paramètres pourront évidemment être modifier lors de la mise en production.

De plus, il est à noté que la suppression de l’affichage d’éventuelles erreurs avec @ devant les fonctions est très lente.

II. Les tests benchmarks tu prendras en compte.

Pour obtenir un même résultat, il existe toujours plusieurs manière. Et bien c’est la même chose en PHP.

Des tests benchmarks permettent de déterminer quel fonction est plus « performante » qu’une autre.

Exemples :

  • echo est plus rapide que print,
  • Mettre ses chaines de caractères entre simple quotes ‘…’ est plus rapide qu’entre des doubles quotes « … »,
  • Utiliser sprintf au lieu de mettre des variables dans des double quotes,

A Lire : Tests et benchmark en PHP 5 de Mathieu Fernandez

III. Register Globals tu désactiveras.

Même si cette directive a été désactivée par défaut à partir de la version 4.2 de PHP, il faut être vigilent sur la désactivation de celle-ci. Activé, elle permettait de récupérer une variable par son nom quel que soit son type (POST, GET, SESSION, …).

Plus d’info : PHPDébutant, Variables globales à OFF.

IV. Ne pas utiliser les short tags tu feras.

Il existe plusieurs manières de déclarer du PHP :

  • <?php et ?>
  • <? et ?>
  • <= et ?>

Une seule de ces écritures est préférable : la première !

Pour 2 raisons :

  • short_open_tags du php.ini est désormais mis à la valeur off par défaut.
  • pas de confusion possible avec le XML

V. Documenter ton code tu feras (enfin).

Par souci de temps, il est facile de ne pas documenter son propre code. Combien de fois j’ai préféré refaire tout un bout de code plutôt que d’essayer de le « décoder ». Désormais, merci de penser à ceux qui reprendrons votre code…

BlogBang

11 commentaires

  1. [...]  Les 5 commandements du développeur PHP () [...]

  2. [...]  Les 5 commandements du développeur PHP (0 visite) [...]

  3. mageekblog dit :

    Bonnes pratiques ? Vraiment ?…

    Sous ce titre, volontairement polémiqueur, se cache en fait une réfléxion que je me suis faite en lisant cet article de devzone. En effet, je suis d’accord pour dire qu’il s’agit effectivement de bonnes pratiques lièes au développement en PHP. …

  4. Moosh dit :

    J’ai du mal avec short open tag. J’ai souvent insisté sur ce point, et considéré qu’il serait bientot deprecated.

    Et non seulement il ne sera pas deprecated, mais en plus il est utilisé dans zendFramework pour Zend_View

    Alors je suis perdu sur cette règle

    Pour rappel <? est déconseillé pour les conflit de sens avec ceux de xml.

    • DevZone dit :

      @Moosh :
      Effectivement bien vue pour le ZF.
      J’avoue ne pas comprendre la raison donnée sur la doc.

      Dans nos exemples et notre documentation, nous utilisons les balises courtes PHP : <? and <?=. De plus, nous utilisons parfois la syntaxe alternative des structures de contrôle. Ce sont des éléments pratiques à utiliser lors de la rédaction de vos scripts de vue, car elles rendent les constructions plus laconiques, et maintiennent les instructions sur des lignes uniques.

      Ceci étant dit, de nombreux développeurs préfère utiliser la forme complète pour des questions de validation ou de portabilité. Par exemple, short_open_tag est désactivé dans le php.ini.recommended, et si vous avez du XML dans vos scripts de vue, alors les balises courtes entraîneront un échec de validation du modèle.

      De plus, si vous utilisez les balises courtes avec un réglage du paramètre à "off", alors les scripts de vue vont soit entraîner des erreurs, soit simplement afficher le code à l'utilisateur.

      Les enveloppes de flux de vue dégradent les performances

      L'utilisation d'enveloppe de flux dégradera les performances de votre application, bien que les tests de performance réels sont indisponibles pour quantifier le niveau de dégradation. Nous recommandons donc soit d'activer les balises courtes, soit de convertir vos scripts pour utiliser la forme longue, ou d'avoir une bonne stratégie de mise en cache partielle ou totale du contenu de vos pages.

  5. www.fuzz.fr dit :

    Les 5 commandements du développeur PHP | DevZone – Zone de développement web…

    Si l’on devait citer 5 règles de bonnes pratiques qu’un développeur PHP professionnel devrait s’appliquer à lui-même, quelles seraient-elle ?…

  6. Mika dit :

    Cependant, il me semble que la conjugaison française met un « s » à la fin du verbe à la seconde personne du singulier « tu prendras ».

  7. d0r1@n dit :

    Très bon post, bien que « gagner du temps » ne soit pas la priorité du coding…

    De plus, la deuxième personne du singulier (« tu ») prend un « s » au futur simple :

    - exemple : tu corrigeraS les fautes de l’article après avoir lu mon commentaire…

    =)

    • devzonefr dit :

      « gagner du temps » ne soit pas la priorité du coding

      non mais : « tenir les délais est la priorité de mon responsable » :)
      Je ne dis surtout pas que c’est bien ni que c’est général, mais juste que (malheureusement) les impératifs de timing provoque facilement des

      « je reviendrai sur ce bout de code plus tard… quand j’aurai le temps »

      no comment pour les fautes d’orthographe ;)

  8. truffo dit :

    Pour les <? dans le Zend_View, Zend permet de les changer à la voler en <?php echo.
    J’avoue que je te rejoint sur ce point, je ne vois en quoi il est néfaste (à part pour des hypothètique problème de portabilité pour ce qui ne savent pas configurer un serveur Web ?).

Déposez un commentaire





Additional comments powered by BackType