• 70 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

Ce cours est en vidéo.

Ce cours existe en livre papier.

Vous pouvez obtenir un certificat de réussite à l'issue de ce cours.

Vous pouvez être accompagné et mentoré par un professeur particulier par visioconférence sur ce cours.

J'ai tout compris !

Codez proprement

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

En programmation comme partout ailleurs, il y a deux types de personnes : celles qui effectuent leur travail rapidement, mais ne se soucient pas de la qualité, de la lisibilité, et de l'évolutivité de leur code , et celles qui font l'effort de soigner un peu leur travail, car elles ont conscience que ce petit travail supplémentaire sera un gain de temps énorme à l'avenir.

Quand on débute, on a tendance à se dire « Ça marche, parfait, ne touchons plus à rien et laissons comme ça ». C'est un mauvais réflexe, et je ne serai pas le seul à vous le dire : n'importe quel programmeur PHP ayant un peu d'expérience sait qu'un code qui fonctionne n'est pas forcément bon.

Cette annexe est en fait une suite de petits conseils apparemment peu importants, sur lesquels je voudrais que vous portiez toute votre attention.
C'est peu de choses, et c'est pourtant ce qui fait la distinction entre un « bon » programmeur et euh… un programmeur du dimanche !

Des noms clairs

J'ai plusieurs fois insisté sur ce point dans les premiers TP du cours, et cette fois j'y reviens avec un peu plus d'explications.
Quand vous créez un script PHP, vous devez inventer des noms. Vous allez devoir donner des noms à différents types d'éléments :

  • les variables ;

  • les fonctions ;

  • les classes.

L'idée est simple : il faut que vous fassiez l'effort de choisir des noms de variables et de fonctions clairs et compréhensibles.
Par exemple, voici de mauvais noms de variables :

  • $temp ;

  • $data ;

  • $info ;

  • $val ;

  • $val2.

Je n'ai pas inventé ces noms de variables ; en fait, pour tout vous dire, ce sont des noms que j'ai vraiment vus dans de nombreux codes source.

Par exemple,$info : « info », oui, mais info sur QUOI ?
C'est pourtant ça qui est crucial : savoir ce que contient une variable. Une variable contient toujours une info, c'est à vous de préciser laquelle.
Je ne vous parle même pas des variables « sans nom » :$temp,$tmpet compagnie. Ces noms sont à bannir absolument.

Mais à quoi ça peut servir de chercher un nom de variable clair ? Après tout, c'est mon code, c'est pour moi, je comprends très bien ce que je fais !

Faux.
Bien sûr que vous savez ce que vous faites (personne n'est dans votre esprit, après tout). Et pourtant le problème peut apparaître dans deux cas.

  • Si vous donnez votre code PHP à un ami pour qu'il vous aide à un endroit où vous bloquez, ou pour qu'il continue votre code. Essayez par exemple de montrer votre code PHP sur des forums sur Internet, vous verrez que si vous utilisez des noms peu clairs, vous aurez beaucoup moins de réponses parce qu'il aura été bien plus difficile de comprendre le fonctionnement de votre code !

  • Un autre cas (sous-estimé), c'est celui où vous retouchez votre code plus tard. Je ne dis pas le lendemain (les idées sont encore fraîches), mais dans trois mois, ou même dans trois semaines. Croyez-en mon expérience : il m'est arrivé de devoir relire mon code source en me demandant « Mais qu'est-ce que j'ai bien pu vouloir faire, là ? ».

Passez ne serait-ce qu'une seconde de plus à réfléchir à des noms clairs. N'ayez pas peur de choisir des noms un peu longs, ce n'est pas une perte de temps, bien au contraire.
Vous pouvez utiliser le symbole underscore « _ » pour remplacer les espaces, qui sont, je vous le rappelle, interdits dans les noms de variables et de fonctions.

Voici quelques exemples de noms de variables clairs :

  • $ip_visiteur ;

  • $pseudo_membre ;

  • $date_news ;

  • $mot_de_passe ;

  • $forum_selectionne.

Pour finir, et en espérant vous convaincre (parce que croyez-moi, c'est très important), voici le même code source en deux exemplaires :

  • le premier contient des noms courts et pas clairs ; il est difficile de comprendre rapidement ce qu'il fait ;

  • le deuxième contient des noms un peu plus longs, mais au moins on arrive tout de suite à savoir à quoi sert telle variable ou telle fonction.

Ces deux codes produisent exactement le même résultat ; simplement, l'un d'eux est beaucoup plus compréhensible que l'autre.

Des noms de variables peu clairs

<?php
$mess_page = 20;

$ret = $bdd->query('SELECT COUNT(*) AS nb FROM livre');

$data = $ret->fetch();
$total = $data['nb'];
 
$nb_total  = ceil($total / $mess_page);
 
echo 'Page : ';
for ($i = 1 ; $i <= $nb_total ; $i++)
{
    echo '<a href="livre.php?page=' . $i . '">' . $i . '</a> ';
}
 
?>

Des noms de variables beaucoup plus clairs

<?php
$nombreDeMessagesParPage = 20;
 
$retour = $bdd->query('SELECT COUNT(*) AS nb_messages FROM livre');
$donnees = $retour->fetch();
$totalDesMessages = $donnees['nb_messages'];
 
$nombreDePages  = ceil($totalDesMessages / $nombreDeMessagesParPage);
 
echo 'Page : ';
for ($page_actuelle = 1 ; $page_actuelle <= $nombreDePages ; $page_actuelle++)
{
    echo '<a href="livre.php?page=' . $page_actuelle . '">' . $page_actuelle . '</a> ';
}
?>

C'est fou comme des noms écrits correctement en français permettent d'y voir plus clair.

Indentez votre code

Une des premières choses qui saute aux yeux quand on regarde un code source, c'est son indentation.

Le principe de l'indentation, c'est d'utiliser intelligemment les tabulations pour « décaler » certaines parties de votre code afin de montrer plus clairement la structure.
La quasi-totalité des éditeurs de texte ont l'habitude que vous utilisiez du code indenté, et vous aident donc beaucoup à clarifier votre code.

Il y a plusieurs « styles » d'indentation de code ; cela varie un peu selon les goûts des développeurs. Celui que je vous propose est simple à retenir :

  • chaque fois que vous ouvrez des accolades{, par exemple pour unif, unwhileou unfor, vous décalez tout le code qui suit d'une tabulation vers la droite ;

  • chaque fois que vous fermez une accolade}, vous décalez tout le code qui suit d'une tabulation vers la gauche.

Avec un code non indenté

C'est plus clair avec un exemple, alors voyez vous-mêmes. Voici ce que ça donne avec un code non indenté :

<?php
for ($ligne = 1 ; $ligne <= 100 ; $ligne++)
{
if ($ligne % 2 == 0)
{
echo $ligne . ' : <strong>ligne paire</strong>';
}
else
{
echo $ligne . ' : <em>ligne impaire</em>';
}
echo '<br />';
}
?>

Avec un code indenté

Et voici maintenant le même code correctement indenté si on respecte la règle des tabulations :

<?php
for ($ligne = 1 ; $ligne <= 100 ; $ligne++)
{
    if ($ligne % 2 == 0)
    {
        echo $ligne . ' : <strong>ligne paire</strong>';
    }
    else
    {
        echo $ligne . ' : <em>ligne impaire</em>';
    }
    
    echo '<br />';
}
?>

L'avantage avec un code indenté, c'est qu'on voit bien les « niveaux » des instructions. On sépare bien les blocs, et on arrive à se repérer bien plus facilement. ;-)
Avoir un code correctement indenté est quasiment indispensable lorsque vous commencez à faire des scripts de plusieurs dizaines de lignes (ce qui arrive assez vite !).

Un code correctement commenté

Le dernier point, qui est peut-être le plus délicat pour des raisons de dosage, concerne les commentaires dans le code.
Les commentaires ne servent à rien, puisqu'ils ne sont pas lus par PHP lors de la génération de la page… comme les noms de variables et l'indentation du code, me direz-vous.

En effet. Mais là encore, les commentaires sont pour vous, et éventuellement pour la personne qui lira votre code. Il faut commenter votre code, mais il ne faut surtout pas tomber dans l'excès !

Je m'explique. Si après une ligne comme celle-ci :

<?php echo $pseudo_visiteur; ?>

… vous rajoutez le commentaire « Affiche le pseudo du visiteur », là je dis non, non et non !

Il est strictement inutile de commenter une à une les lignes de votre code ! Si j'ai insisté tout à l'heure pour que vous choisissiez des noms de variables et de fonctions clairs, c'est justement pour vous éviter d'avoir besoin de trop commenter.

Le plus judicieux et le plus intelligent, c'est de commenter un « groupe de lignes » pour expliquer brièvement à quoi elles servent quand cela n'est pas évident.
C'est le sens général de votre code que vous devez expliquer dans les commentaires, et non pas le rôle de chaque ligne !

Pour vous aider, on peut distinguer deux types de commentaires :

  • ceux qui commencent par// : ils permettent de commenter sur une seule ligne à la fois ;

  • ceux qui commencent par/*et qui se terminent par*/ : ils sont utilisés pour de longs commentaires s'étalant sur plusieurs lignes.

Voici une petite illustration d'un code correctement commenté :

<?php
/*
Script "Questionnaire de satisfaction"
    Par M@teo21
    
Dernière modification : 20 août XXXX
*/

// On vérifie d'abord s'il n'y a pas de champ vide
if ($_POST['description'] == NULL OR $_POST['mail'] == NULL)
{
    echo 'Tous les champs ne sont pas remplis !';
}
else // Si c'est bon, on enregistre les informations dans la base
{
    $bdd->prepare('INSERT INTO enquete VALUES (\'\', ?, ?)');
    $bdd->execute(array($_POST['description'], $_POST['mail']));    
    
    // Puis on envoie les photos
    
    for ($numero = 1 ; $numero <= 3 ; $numero++)
    {
        if ($_FILES['photo' . $numero]['error'] == 0)
        {
            if ($_FILES['photo' . $numero]['size'] < 500000)
            {
                move_uploaded_file($_FILES['photo' . $numero]['tmp_name'], $numero . '.jpg');
            }
            else
            {
                echo 'La photo ' . $numero . 'n\'est pas valide.<br />';
                $probleme = true;
            }
        }
    }
    
    // Enfin, affichage d'un message de confirmation si tout s'est bien passé
    
    if (!(isset($probleme)))
    {
        echo 'Merci ! Les informations ont été correctement enregistrées !';
    }
}
?>

Comme vous le voyez, je n'ai pas commenté toutes les lignes. J'ai juste commenté des groupes de lignes pour expliquer leur fonction globale, ce qui permet à l'auteur (moi ou un autre) de se repérer beaucoup plus facilement dans le code plus tard !

Les standards

Vous l'aurez compris, lorsque nous travaillons en équipe, il est important de garder une certaine cohérence dans la manière d'écrire du code. Cela sera d'autant plus important lorsque vous développerez avec un framework tel que Symfony.

Un collectif de développeurs s'est réuni pour établir des standards à suivre en ce qui concerne l'écriture de code PHP. Ce consortium s'appelle le FIG (Framework Interop Group) et a surtout été créé pour faire en sorte que l'ensemble des frameworks PHP respectent des règles communes.

Les standards sont appelés "PSR" (PHP Standards Recommendations) et il y en toute une liste. Vous pouvez les retrouver ici : liste des PSR.

Je vous propose de vous attarder sur deux d'entres elles :

  • la PSR-1, règles basiques en rapport avec le standard de codage,

  • et la PSR-2, guide du coding style.

Ces standards renferment tout un ensemble de règle qu'il faut suivre. Je vous invite donc à les lire attentivement.

Il se peut que vous fassiez tout de même des erreurs… Il existe un outil pratique qui automatise la correction de votre code au regard des règles imposées. Je vous invite donc à utiliser PHPCS-Fixer.

C'est un outil qui ne s'utilise qu'en ligne de commande. Vous retrouverez les étapes d'installation ici (en anglais). Je vous invite vivement à utiliser cet outil pour faire en sorte que votre code respecte les règles de codage.

Vous êtes demandeur d'emploi ?
Sans diplôme post-bac ?

Devenez Développeur web junior

Je postule
Formation
en ligne
Financée
à 100%
Exemple de certificat de réussite
Exemple de certificat de réussite