Sorcellerie Web - Tag - php

Ali Baba et les 40 mauvaises pratiques du programmeur (PHP)

J.Ducastel — Thu, 14 Feb 2008 18:39:00 +0100

Je suis tombé via le planet PHP sur une liste de 40 points qui font un mauvais programmeur PHP. Je vais essayer de la traduire et de la commenter.

1 - Ne pas commenter son code proprement suivant un standard comme phpDoc: C'est le service minimum en matière de commentaires. Il est vital de savoir ce qu'une fonction attend en parametre et ce qu'elle retourne. De plus, cela permet la génération d'une documentation; et certains éditeurs tels que Komodo edit s'en servent pour afficher une aide en ligne lorsque vous y faites appel .
2 - Ne pas voir le bénéfice d'un bon outil de développement intégré tel que Zend Studio ou Eclipse.: Ces usines à gaz ? Non, désolé.
3 - N'avoir jamais utilisé d'outil de contrôle de versions tel que Subversion: Plus que la qualité du programmeur, je crois que c'est surtout une question de projet. Pour une appli professionnelle ou un projet open source, c'est vital, mais on n'a pas toujours un serveur subversion sous la main pour un site perso....
4 - Ne pas adopter de convention de codage et de nommage et s'y tenir, au moins à l'échelle d'un projet.: Qui ne s'est pas déjà arraché les cheveux avec le nom des fonctions natives php (avec ou sans underscore), et pire l'ordre des arguments qui varie d'une fonction à l'autre ?
5 - Ne pas adopter une méthodologie constante: Faudrait déjà en avoir une. Personnellement, je suis plutôt habitué à La Rache.
6 - Ne pas échapper ou valider les variables pour les requêtes SQL: Là c'est plus de la mauvaise programmation, c'est l'amour du risque.
7 - Ne pas planifier l'application avant de commencer à coder.: Dans un monde idéal, les utilisateurs sauraient ce qu'ils veulent les spécifications ne changeraient pas tous les trois mois. Dans un monde idéal.
8 - Ne pas pratiquer le développement dirigé par les tests.: Les test unitaires, c'est bon. Mangez-en.
9 - Désactiver l'affichage des erreurs: La première fois qu'on l'active, ça fait mal. Mais après, c'est tellement bon. Et surtout, cela permet généralement de préparer en douceur la prochaine mise à jour de PHP.
10 - Ne pas voir les bénéfices d'un débogueur: Il n'y a qu'un débogueur ici, c'est moi. Sans rire, pour un langage web interprété, le débogueur, c'est un petit coup de rafraichissement de la page. Non ?
11 - Ne pas refactoriser son code: On peut faire autrement ? Mon nom est Refactoring. Constant Refactoring.
12 - Ne pas séparer les couches de traitement en utilisant un motif tel que MVC.: Ou MVT. Elementaire, mon cher Django.
13 - Ne pas connaitre les acronymes KISS, DRY, MVC, OOP, REST: Mouais, pas besoin de connaitre les acronymes pour pratiquer.
14 - Ne pas retourner de contenu mais faire des print() depuis les fonctions et classes: Autrement dit, éviter les effets de bord. Et appliquer le principe de la séparation des couches de traitement.
15 - Ne pas connaitre les avantages des tests unitaires et des tests en général: On avait pas dit DRY ? cf #8
16 - Retourner du html au lieu de données / objets: Pareil, voir #14
17 - Coder en dur les messages et les parametres de configuration: Coder en dur, c'est mal
18 - Ne pas optimiser ses requetes SQL: Je veux bien, mais qui le fait vraiment au lieu de juste le prétendre ?
19 - Ne pas utiliser __autoload(): J'ai la malchance de maintenir des applications PHP4. Mais j'ai mieux qu'autoload : Webappkit"
20 - Ne pas autoriser la gestion intelligente des erreurs: ???
21 - Utiliser GET au lieu de POST pour toutes les actions de destruction: Ca, c'est pour les applications accessibles aux moteurs de recherche. Qui suivront tous les liens en GET qu'ils trouveront. Et ne savent pas si cela correspond à un document ou une action sur un document. Trop dur pour vous.
22 - Ne pas savoir se servir des expressions régulières: Qui voudrait se priver de si belles migraines ?
23 - N'avoir jamais entendu parler d'injection SQL ou de scripting multisites
24 - Ne pas permettre de configurer simplement ses classes, que ce soit par arguments passés au constructeur, via des méthodes dédiées ou des constantes: Je suis moi-même un fanatique de la configurabilité. Un bon script générique avec une configuration spécifique peut parfois permettre de s'économiser bien des lignes de code. C'est ce qui a présidé au concept des Outils (Tools) pour Webappkit.
25 - Ne pas connaitre les bénéfices et limitations de la programmation orienté objet: J'ai du mal à me souvenir de ma brève période procédurale puis fonctionnelle...
26 - Mal utiliser la POO
27 - Penser que du code réutilisable implique du code POO: Parfois une bonne fonction peut suffire, mais ça devient rare...
28 - Mal choisir ses valeurs par défaut
29 - Ne pas avoir un unique fichier de configuration: Pas d'accord. Les premières versions de webappkit fonctionnaient comme cela et pour de grosses applis, cela devient un enfer à maintenir. D'autant que tout n'est pas forcément utilisé et ralentit donc inutilement le tout.
30 - Croire masquer le contenu d'un script en le renommant .inc au lieu de .php
31 - Ne pas utiliser une couche d'abstraction de base de données.: Je plaide coupable. Je suis masochiste et je préfère faire mon SQL à la main.
32 - Se répéter. Si vous devez faire du copier-coller de code, il y a sans doute une erreur de design.
33 - don't make a function/class/method do just one thing and don't make them interact.: Moi pas compris. Toi parler moi ?
34 - Ne pas se servir des mécanismes objets tels qu'interface, héritage multiple et (modifeurs d'accès ?)
35 - Ne pas optimiser l'architectire de son application en suivant les motifs de conceptions éprouvés.
36 - Ne pas autoriser les chemins relatifs: Les chemins absolus, c'est le mal. Vous brulerez en enfer pour cela.
37 - Polluer l'espace de nommage global en en préfixant pas ses noms de fonctions.
38 - Ne pas autoriser le prefixage des tables de sa base de données
39 - Utiliser un moteur de gabarits séparé: Hein ? Quoi ? Qu'est-ce qu'il entend par "séparé" ?
40 - Ne pas s'inspirer des frameworks PHP existants: Les frameworks Python, ça compte ?

Fichiers de configuration

J.Ducastel — Fri, 07 Dec 2007 16:27:00 +0100

Lorsqu'on développe une application ou un composant de manière à pouvoir le réutiliser, il est nécessaire de pouvoir définir une configuration d'environnement de manière séparée du code. Cela peut être fait par inclusion d'un fichier se contentant de déclarer un suite de variables ou de constantes dans le language de l'application (c'est le cas des fichiers urls.py et settings.py de Django). Mais il est généralement préférable d'utiliser un format qui puisse être lu et modifié par un non-programmeur.

Le format INI

A la fois très simple et très largement utilisé, le format INI permet de définir des paires clefs/valeur, éventuellement organisées par sections. Il est suffisamment intuitif pour être modifié par quelqu'un qui n'en connait pas la syntaxe.

C'est le format de configuration de PHP, et une fonction native permet de lire un tel fichier et de récupérer directement les données stockées dans un tableau associatif, à deux dimensions en activant le support des sections.

Python dispose du module ConfigParser, qui supporte une syntaxe un peu plus évoluée.

Le format XML

Le patriarche des formats de structuration et d'échange de données. Plus qu'un format de fichier, XML est une grammaire dont dérivent des zillions de syntaxes, qu'elles soient standardisées ou propriétaires. Très largement utilisé pour la configuration d'application, ce n'est pourtant pas forcément des plus simples à éditer. De plus, il est généralement assez lourd à manipuler en programmation, ce qui n'est pas terrible en termes de performance. Surtout dans le cadre d'une application web, si celle-ci doit lire le fichier à chaque requete...

Le format YAML

Si vous avez besoin de données de configuration plus élaborées, notamment s'il vous faut plus de deux niveaux de données ou des textes sur plusieurs lignes, il y a le format YAML. Celui-ci se veut une alternative à XML, qui soit à la fois plus concise (donc plus légère à stocker) et plus lisible pour un être humain. Ce qui en fait un candidat idéal pour des fichiers de configuration. Comme en Python, l'indentation y joue un rôle clef.

Contrairement à INI, il n'est pas supporté nativement par PHP, mais la librairie Spyc permet de convertir ces fichiers en tableaux de données et inversement.

Python dispose de la librairie PyYaml.

Détecter les préférences du navigateur

J.Ducastel — Mon, 03 Dec 2007 19:34:00 +0100

Il bien plus agréable pour l'internaute de disposer directement du contenu qui le concerne (langue, navigateur, OS...) plutot que de devoir fouiller le site web pour l'obtenir. Cela améliore son expérience de navigation, et donc l'attrait pour votre site.

Beaucoup d'entre nous se sont habitués à chercher, en arrivant sur un site, s'il n'en existait pas une version dans sa propre langue. On cherche alors où sont les petits drapeaux, les micro-liens avec code de langue sur deux caractères, etc. Et beaucoup d'utilisateurs ne les trouvent pas, et quittent le site immédiatement, faute de pratiquer la langue affichée. Pourtant, quand le contenu d'un site est traduit, le plus gros du travail est fait; pourquoi ne pas l'afficher directement dans la langue spécifiée par l'internaute pour son navigateur ?

Ceci est également valable pour d'autres préférences. La page de téléchargement de Firefox par exemple est non seulement traduite dans la langue de l'internaute, mais la version proposée au téléchargement est celle correspondant à son système d'exploitation. Tout aussi efficace, la page de bookmarklets pour Del.icio.us est automatiquement adaptée au navigateur en cours. Ceci est possible grâce aux données de préférences et d'environnement utilisateur transmises par le navigateur au serveur web via les en-têtes HTTP.

Outre les préférences de langue, et les particularités eventuelles de l'environnement système d'exploitation/navigateur, il peut être souhaitable de détecter le support de javascript, surtout pour les sites utilisant ajax pour certaines de leurs fonctionnalités. Tout comme le support de flash. La liste est longue, car les possibilités d'HTTP sont encore largement sous-utilisées.

Bien evidemment, il faut garder à l'esprit que ces données ne sont pas fiables, et ne doivent être utilisées que pour définir la version du contenu par défaut, et toujours permettre à l'utilisateur de modifier ces réglages si possible via des liens et des contrôles manuels.

Pour ce qui est de PHP, vous pouvez utiliser un de mes bouts de script ( getting browser language settings with php), ou la classe phpsniff qui semble bien plus complete (pas encore utilisée, je viens de tomber dessus).

Optimisation PHP : les chaines de caractères

J.Ducastel — Fri, 30 Nov 2007 12:16:00 +0100

Voici une petite astuce concernant les chaînes de caractères pour optimiser vos scripts PHP, que certains découvriront peut-être. Prenez l'habitude d'utiliser les apostrophes (simple quotes) plutôt que les guillemets (double quotes). Ceci parce que les chaines entre guillemets peuvent contenir des variables qui seront évalués à l'éxécution. Par exemple :

$uper_riche='Picsou';

// ceci affiche : Bonjour, je suis Picsou
echo "Bonjour, je suis $uper_riche";

// alors que ceci affiche : Bonjour, je suis $uper_riche
echo 'Bonjour, je suis $uper_riche';

// on peut utiliser les accolades pour acceder à des noms complexes
$Picsou->neveux=array('Riri','Fifi','Loulou');
// ceci affichera : Le second neveu de Picsou est Fifi, il en a trois
echo "Le second neveu de Picsou est {$Picsou->neveux[1]}, il en a trois";

Ce qui double son travail, car le code est d'abord interprété une première fois à la lecture du script et découpé en blocs sémantiques (chunks) : variables, chaines, instructions etc. Une chaine entre apasotrophes sera alors conservée telle quelle jusqu'à la fin de l'execution du script, alors qu'une chaine entre guillemets devra être interprétée à chaque évaluation. Par conséquent, il vaut mieux les éviter autant que possible. Par exemple :

/**
* on construit une chaine de caracteres dynamiques en separant bien les chunks variables des blocs statiques
*/
$html='<p>Bonjour, je suis '.$uper_riche.'</p>';

/**
* on ne force pas l'evaluation du parametre passe a une fonction
*/
echo 'Qui est le plus riche ? '.strtoupper('picsou !');

/**
* idem pour les clefs d'un tableau associatif
*/
echo $personnages['picsou']['neveux'][1];

C'est le genre de petites choses qui peuvent paraitre évidentes une fois devenues une habitude, mais qui ensuite évitent de plomber vos scripts inutilement.

Webappkit : un système de paquets pour PHP

J.Ducastel — Wed, 28 Nov 2007 00:14:00 +0100

Le but de Webappkit, c'est de faciliter la réutilisation et le partage de briques logicielles PHP pour les applications web. Pour les développeurs, cela permet de se concentrer sur le code spécifique de l'application en facilitant l'intégration de librairies génériques existantes. Pour les simples bidouilleurs ou webmestres, de créer leur site en assemblant des applications existantes telles que blog, forum, suivi statistique etc.

C'est un de mes projets, et un logiciel libre hébergé sur Google Code. Initialement, il s'agissait d'un meta-framework permettant de définir une pile de scripts à exécuter pour une url ou une branche du site. Depuis la version 0.8, j'ai changé d'approche pour me concentrer sur un système de paquets nommés kits et qui peuvent contenir de la simple librairie (avec gestion des dépendances) à l'application complète.

Tout naturellement, j'ai organisé mes propres librairies sous formes de kits. Elles sont incluses dans l'archive disponible au téléchargement, et je les détaillerai ici prochainement. Télécharger webappkit (la version actuelle est 0.9 alpha). Le projet dispose de son propre blog (en anglais), pour en suivre l'actualité, ainsi qu'un groupe de discussion google.

Utiliser un kit de librairie

Commençons par détailler l'usage le plus simple : un kit de librairie. Concrètement, les kits sont des dossiers à regrouper dans un même repertoire accessible par vos scripts (généralement webappkit/). Pour charger un kit, il faut alors appeler :


/**
* inclusion des librairies du base de webappkit
*/
include_once('webappkit/include-me.php');
/**
* les librairies du kit sont alors incluses, ainsi que les dependances
*/
Webappkit::loadKit('mon_kit');

Les kits peuvent également être organisés en arborescence, un kit contenant lui même des kits ;il est alors possible de charger directement un sous-kit si l'on n'a pas besoin du paquet total. D'ailleurs, charger un kit ne chargera pas nécessairement tous ses sous-kits, il est possible de définir les sous-kits qui seront chargés lors de l'appel du kit parent.


/**
* chargement d'un sous-kit
*/
Webappkit::loadKit('mon_kit.un_sous_kit');

Dans les prochains billets, je détaillerai les usages plus avancés, ainsi que la construction des kits.

PHP : classe datapath

J.Ducastel — Wed, 25 Oct 2006 15:58:00 +0200

Cette classe permet d'accéder à une variable multidimensionnelle (tableaux et objets) via une syntaxe d'adressage. Le but etant de pouvoir manipuler dynamiquement de tels objets.

Toutes les methodes de cette classe sont à usage statique, et travaillent directement sur une référence de la variable à manipuler.


$data=array(
  'membres'=>array(
    array('nom'=>'dupont','prenom'=>'michel')
    , array('nom'=>'martin','prenom'=>'roselyne')));

// ceci va afficher roselyne
echo datapath::get($data,'membres.1.prenom');

// ceci ajoute un element
$membre=array('nom'=>'dupuis','prenom'=>'pascal');
datapath::set($data,$membre,'membres.2');

Méthodes publiques

string separator([string $new]) : retourne le separateur actuel de segments de chemin (. par defaut
mixed get(mixed &$data, string $path) : retourne l'element pointé par le chemin $path.
bool set(mixed &$data, mixed $value, string $path) : definit la valeur de l'element pointé par le chemin $path au sein de la variable $data.
bool setRef(mixed &$data, mixed $ref, string $path) : definit par référence la valeur de l'élément pointé par le chemin $path au sein de la variable $data.

Quelques methodes supplémentaires sont prévues, notamment en ce qui concerne l'itération, l'application de fonctions, tri, test etc.

Est également prévu une extension de la syntaxe, avec l'ajout de jokers et/ou de selecteurs de valeur à la xpath.

Edit 28/11/2007 : Télécharger le kit de la classe (voir le billet Webappkit)

Getting browser language settings with PHP

J.Ducastel — Tue, 13 Sep 2005 20:02:00 +0200

So, you run a multilingual web site with PHP and you want to serve the reader's choice language if available. No problem, HTTP carries user's browser language settings within Accept-Language instruction, you just have to parse it. Here is a sample function.

function parseHttpAcceptLanguage($str=NULL) {
        // getting http instruction if not provided
        $str=$str?$str:$_SERVER['HTTP_ACCEPT_LANGUAGE'];
        // exploding accepted languages 
        $langs=explode(',',$str);
        // creating output list
        $accepted=array();
        foreach ($langs as $lang) {
                // parsing language preference instructions
                // 2_digit_code[-longer_code][;q=coefficient]
                ereg('([a-z]{1,2})(-([a-z0-9]+))?(;q=([0-9\.]+))?',$lang,$found);
                // 2 digit lang code
                $code=$found[1];
                // lang code complement
                $morecode=$found[3];
                // full lang code
                $fullcode=$morecode?$code.'-'.$morecode:$code;
                // coefficient
                $coef=sprintf('%3.1f',$found[5]?$found[5]:'1');
                // for sorting by coefficient
                $key=$coef.'-'.$code;
                // adding 
                $accepted[$key]=array('code'=>$code,'coef'=>$coef,'morecode'=>$morecode,'fullcode'=>$fullcode);
        }
        // sorting the list by coefficient desc
        krsort($accepted);
        return $accepted;
}

This function will parse a given HTTP Accepted language instruction (or retrieve it from $_SERVER if not provided) and will return a sorted array. For example, it will parse fr;en-us;q=0.8 to :

[1.0-fr]=>([code]=>'fr','morecode'=>'fr',[coef]=>'1.0',[fullcode]=>'fr')
,[0.8-en]=>([code]=>'en','morecode'=>'us',[coef]=>'0.8',[fullcode]=>'en-us')

The next thing will be to find and serve the first available version amongst user's accepted languages. Easy.

PHP4 singleton

J.Ducastel — Mon, 16 May 2005 17:45:00 +0200

Quickly, a generic method to get a singleton in php4. Juste paste this method in your class definition.

function & getSingleton() { $class=__CLASS__; // getting current
class name // need to build singleton ? if
(!isset($GLOBALS['singletons'][$class])) { // getting arguments to forward
$args=func_get_args(); /* building instanciation code, forwarding arguments
creating singleton and a single global reference per class name */
$eval='$GLOBALS[\'singletons\'][$class]=& new $class('; // adding arguments
to constructor for ($f=0; $f<count($args); $f++) $eval.='$args['.$f.'],'; //
deleting last unnecessary ',' and closing call $eval=substr($eval,0,-1).');';
// executing instanciation code eval($eval); } // throwing instance return
$GLOBALS['singletons'][$class]; }

So you can get a single instance of your class with a static call of getSingleton, like your_class::getsingleton($arg1, $arg2,...);. You can edventually add an alert in the class constructor like this :

function the_class_constructor_method() { if
(isset($GLOBALS['singletons'][__CLASS__])) { trigger_error("Use
".__CLASS__."::getSingleton(); to get a single instance of ".__CLASS__); }
}

Please note that this isn't the clean, righteous way to implement Singleton pattern : because in php4 it seems not possible to have the class constructor returning anything else than a new instance of the class, nor to make the constructor private. Therefore it is still possible to have multiple instances of the class, by calling its constructor directly.