Bonnes pratiques de programmation

Bonjour, et bienvenue dans cette leçon. Nous allons nous intéresser aujourd’hui aux bonnes pratiques de programmation.

Programmer ne consiste pas seulement à écrire des lignes de code les unes après les autres. C’est une activité complexe et exigeante, qui demande une certaine maîtrise. Je vais vous présenter quelques bonnes pratiques importantes, à garder en permanence à l’esprit lorsque vous codez.

Tout d’abord : n’optimisez pas tout de suite ! Comme nous le verrons dans les semaines à venir, programmer revient souvent à chercher le meilleur compromis entre la correction du code et sa rapidité.

Le problème, c’est que la rapidité s’obtient en exploitant des structures de données adaptées, des algorithmes élaborés, et parfois même des astuces de bas niveau pour accélérer les calculs. Bien souvent, ces optimisations pèsent sur la lisibilité du code, et il devient plus difficile de voir ce qu’il fait.

Commencez donc toujours par obtenir un programme correct : la rapidité n’a pas à être un critère à ce stade, et les optimisations pourront venir plus tard. Il est toujours bien plus simple de déboguer un code écrit pour être correct qu’un code écrit pour être rapide.

Programmer est difficile, et ce n’est un secret pour personne. Pourquoi ? Parce que les langages de programmation ne sont pas faits pour être compris facilement par des humains, mais pour être traités facilement par des machines.

Écrire du code, c’est décrire explicitement et sans ambiguïté les détails d’une méthode donnée. Autrement dit, c’est décrire cette méthode à l’aide des notions élémentaires offertes par un langage de programmation.

La plupart du temps, un(e) programmeur(se) ne raisonne pas au niveau du langage lui-même : il ou elle s’appuie sur des couches d’abstraction.

Prenons l’exemple de la recherche d’un plus court chemin dans un graphe : il n’existe pas de fonction find_the_shortest_path en Python. Nous allons donc la programmer, pour pouvoir ensuite nous en servir dans des tâches plus complexes.

Programmer, c’est empiler des couches de plus en plus abstraites, jusqu’à ce que votre programme puisse s’écrire à l’aide de quelques fonctions seulement.

Dans ce cours, nous utiliserons la théorie des graphes pour jouer dans un labyrinthe. Nous commencerons par trouver des chemins, puis le plus court d’entre eux, puis plusieurs plus courts chemins, et enfin nous tiendrons compte de l’adversaire.

C’est ce que l’on appelle structurer le code, et un code devrait toujours être structuré. En règle générale, essayez d’écrire des fonctions qui ne dépassent pas une quinzaine de lignes : au-delà, il est sans doute temps de découper votre fonction en plusieurs sous-fonctions.

Un(e) programmeur(se) ne devrait jamais, au grand jamais, utiliser le copier/coller pour développer un code.

Si l’envie vous en prend malgré tout, créez plutôt une sous-fonction contenant les lignes que vous vouliez dupliquer.

C’est très important, car un jour vous voudrez modifier votre code, le faire évoluer pour prendre en compte de nouvelles entrées, ou en optimiser une partie. Tout est bien plus simple quand ce qu’il faut mettre à jour se trouve à un seul endroit.

Une source d’erreurs fréquente est de modifier des lignes dupliquées en oubliant les autres occurrences présentes dans le code.

Tout ce qui paraît arbitraire dans un code est à éviter. Par exemple, vous pourriez vouloir utiliser l’infini dans votre code, mais une telle valeur n’existe pas dans la mémoire d’un ordinateur.

Une astuce consiste à utiliser à la place un grand nombre, disons 100 000, défini une seule fois au début de votre code sous un nom explicite, comme infinity_value. Lorsque vous relirez ce code, peut-être des années plus tard, il sera bien plus facile de comprendre ce qu’est infinity_value que ce qu’est 100 000.

Enfin, écrivez toujours votre code en pensant qu’il sera lu par quelqu’un d’autre. C’est évidemment le cas si vous travaillez en équipe, mais même seul(e), ajouter des commentaires est un bon moyen de vous assurer que ce que vous faites est correct.

Une bonne façon d’utiliser les commentaires est de les écrire d’abord, puis d’ajouter le code avec parcimonie entre eux. Si vous ne savez pas quels commentaires écrire, commencez par une description explicite de la fonction avant d’écrire le code correspondant : une courte description de son fonctionnement, le détail de ses paramètres et de ses sorties, et des remarques sur ses conditions de correction.

Programmer n’est pas, et ne devrait jamais être, une question de nombre de lignes écrites par minute. S’il faut une heure pour écrire une ligne, qu’il en soit ainsi : peut-être cette ligne sera-t-elle utilisée par des centaines ou des milliers de programmeur(se)s, et elle vaudra alors chaque instant que vous y aurez passé.

Si vous suivez tous ces principes, vous avez toutes les clés pour devenir un(e) excellent(e) programmeur(se). Merci d’avoir suivi cette leçon, et à la prochaine fois !