Programmation PHP/Concevoir du code de haute qualité
Un livre de Wikibooks.
| Programmation PHP |
| Département Informatique |
 |
| Plan |
|
| Modifier ce modèle |
Sections |
[modifier] Introduction
La programmation est accessible à tout le monde. En revanche, créer du code de qualité demande une rigueur et une organisation qui n'est pas toujours au rendez-vous. Voici donc un tutoriel pour apprendre à programmer du code de haute qualité. Les exemples seront pris au PHP mais leur application est toujours valable quel que soit le langage de programmation.
[modifier] Pourquoi bien programmer ?
Il est important d'aborder cette question dès le début pour légitimer ce cours, la motivation étant un facteur non négligeable de l'apprentissage.
Le bien-programmer est tout d'abord indispensable pour travailler en équipe. Lorsque vous travaillez dans un projet avec d'autres développeurs, il est important de coordonner votre action, d'éditer du code lisible... ce qui augmentera considérablement votre rendement de travail.
Vous vous apercevrez rapidement qu'un code bien programmé simplifie la vie: Lorsque vous avez créé un script une année auparavant et que vous devez vous replonger dessus, vous serez heureux de gagner du temps en retrouvant plus facilement le sens du code grâce à sa lisibilité. De plus, du bon code est plus compatible et générera moins d'erreurs ...
La quantité toujours grandissante de développeurs risque d'entraîner une saturation du marché. Vous serez jugés sur votre qualité de programmation. Un code aux normes est un sceau garantissant votre compétence de développeur.
[modifier] Les critères de qualité
La programmation doit posséder des qualités qui ne sont pas arbitraires. Chaque critère sera accompagné d'une rapide description de son utilité.
[modifier] La portabilité
La portabilité du code est son degré d'indépendance à son environnement.
Cette qualité est surtout requise pour des scripts destinés à être utilisés par le grand public. Par exemple, lorsqu'en PHP, vous utilisez des balises <?, vous réduisez la portabilité du code. En effet, l'usage des balises de ce type nécessite l'activation de la fonction SHORT_TAGS, donc dépend de l'environnement du script. Par définition, cela réduit la portabilité du code. Il vaut mieux utiliser la balise <?php qui marche quel que soit l'environnement.
[modifier] La lisibilité
Il n'est pas besoin de chercher loin pour trouver les avantages que confèrent un code lisible: il permet aux autres développeurs de modifier plus facilement votre script, mais également à vous-même de comprendre plus rapidement un de vos anciens programmes. La lisibilité du code permet également d'éviter les erreurs de logique qui apparaissent plus distinctement.
La lisibilité est très liée à la définition de normes.
La lisibilité du code inclut un bon usage de la commentarisation. Les commentaires sont faits pour augmenter la rapidité de compréhension du script par le développeur, mais il ne doit pas en être fait un usage excessif, lequel serait néfaste pour la lisibilité. Voici un exemple de mauvaise utilisation des commentaires:
/* Code qui va afficher "salut" par un echo. Ce programme est fait en PHP compatible php3*/ echo "salut"; //affiche "salut" #fin du programme
Il devient difficile de distinguer le code parmi les commentaires. Cet exemple était volontairement exagéré, mais n'est pas si loin de quelques scripts que l'on peut trouver sur le Net.
[modifier] La définition de normes
Les normes sont des décisions le plus souvent arbitraires sur des méthodes de programmation. L'important n'est pas ce que définissent les normes, mais que des normes soient définies.
La définition de normes confère une continuité logique au code. Par exemple, en PHP, il est possible de nommer des variables de 2 manières différentes :
$maSuperVariable //Ecriture en "camel caps" $ma_super_variable //Ecriture avec des underscores
Vous serez rapidement désorienté si tantôt vous utilisez une méthode, tantôt une autre, et il se peut que vous perdiez des heures à chercher la cause d'une erreur d'écriture de variable.
De plus, lorsque vous travaillez en commun avec d'autres développeurs, si vous n'avez pas défini le nom du fichier de connexion à la base de données, lors de la fusion des scripts, vous devrez tout remodifier et perdre ainsi un temps précieux.
[modifier] L'unicité du code
L'unicité du code est le principe selon lequel aucun code ne doit être double dans le script. Ce critère a un enjeu pratique et vise à augmenter la rapidité des modifications d'un script. Prenons un exemple:
Vous faites un programme de comptabilité d'entreprise et vous vous connectez à une base de données. Si dans chaque page où vous vous connectez, vous entrez le code suivant :
<?php
$connect = mysql_connect('host','account','password');
//actions sur la BDD
?>
Le jour où vous voudrez changer le mot de passe de la base de données, vous devrez modifier chaque script, tâche qui s'avère laborieuse. Si en revanche lorsque vous vous connectez à la base de données vous entrez le code suivant :
include 'connect.php';
Et que dans le fichier connect.php vous entrez les informations de votre base de données, vous n'aurez qu'à modifier ce seul fichier lors d'un changement de mot de passe.
[modifier] Exemple concret
Créez un fichier conf/config.php dans lequel vous mettez vos information de connexion à la base de données :
define('HOST', 'localhost');
define('USER', 'moi');
define('PASS', 'mon_mdp');
define('DB', 'mon_site');
define('PREFIX', 'mon_site_'); // Préfixe des tables SQL
Lorsque vous ferez une requête, vous la ferez de la manière suivante :
mysql_connect(HOST, USER, PASS);
mysql_select_db(DB);
$temp = mysql_query('SELECT * FROM '. PREFIX .'ma_table');
[modifier] La gestion des erreurs
Votre programme ne doit pas afficher au client de message d'erreur. Cela ne signifie pas non plus qu'il faille les étouffer. Il faut par du code de qualité réduire au maximum les erreurs possibles, puis traiter les autres en les enregistrant par exemple dans un fichier.
Pour créer une bonne gestion des erreurs, partez du principe que l'utilisateur est imprévisible et qu'il va justement faire ce qu'il ne faut pas. Envisagez toutes les possibilités et trouvez-y une solution.
[modifier] Les conflits de critères
Réaliser un programme rassemblant toutes les qualités présentées précédemment est extrêmement difficile. La plupart du temps, certains critères entrent en conflit, par exemple entre la compatibilité et la lisibilité. Il va alors falloir établir une hiérarchie.
Il n'existe pas de hiérarchie absolue. Elle dépend du type de projet que vous menez. Voici quelques exemples de hiérarchisation de critères en fonction du projet:
[modifier] Projet destiné au grand public
Par exemple, vous décidez un jour de concevoir un cms. Les qualites requises seront:
- La portabilité du code (car le cms doit fonctionner sous le plus grand nombre de serveurs, donc doit dépendre le moins possible de sa configuration)
- La gestion des erreurs (sachant que les personnes qui vont utiliser le script ne l'ont pas fait, il ne doit pas retourner de message d'erreur car ils ne pourraient pas l'arranger)
- La définition de normes (vous le programmerez certainement en équipe, donc il faut coordonner votre action)
- La lisibilité du code (toujours pour des raisons de coordination)
[modifier] Script pour un particulier
Si on vous demande de programmer un système de restriction d'accès pour un site particulier, il va falloir que le code possède les critères suivants:
- La lisibilité du code (Un autre développeur doit pouvoir facilement modifier votre script si le client le lui demande)
[modifier] Erreurs à éviter
Attention à ne pas vous laisser avoir par des idées fausses d'autant plus dangereuses qu'elles sembleraient logiques. En voici quelques exemples:
[modifier] Le code optimisé
Certaines personnes croient que le code le plus court est également le plus rapide d'exécution, ce qui est faux. En voici un contre-exemple:
//Code le plus court
for ($i=0; $i<count($array); $i++)
{
echo $array[$i];
}
//Code le plus rapide
$count = count($array);
for ($i=0; $i<$count; $i++)
{
echo $array[$i];
}
En effet, avec le premier code, à chaque itération, la taille du tableau est recalculée, ce qui ralentit le script. Le code le plus court n'est donc pas le plus rapide d'exécution.
