Un programme informatique est une suite d’instructions exécutée par un processeur. Le processeur est le cerveau de l’ordinateur. Au début, les développeurs écrivaient dans un langage compris directement par le processeur. On parlait de langage machine. L’inconvénient de ce langage est qu’il est incompréhensible par les humains autres que les concepteurs du processeur et quelques développeurs. De plus, en 40 ans les processeurs se sont complexifiés.
Un langage au dessus de ce langage machine a donc été créé pour pouvoir décrire le programme à réaliser. Il s’agit de l’assembleur. Ce langage est très efficace mais il reste encore difficilement manipulable même pour les initiés. D’année en année, d’autres langages ont été créés et permettent de décrire plus facilement les besoins des utilisateurs. Pompeux paradigmes. Un des objectifs des langages de programmation est de devenir naturel. Ainsi, n’importe qui pourra écrire ses programmes ou presque.
En effet, il faut une certaine logique pour décrire les besoins des utilisateurs. Cette logique est nommée algorithmie. Bien sûr, certains promettent que l’intelligence artificielle permettra un jour de créer des programmes en écoutant les besoins des utilisateurs, mais il faudra qu’elle soit patiente. Dans l’article ‘Le client : maïeutique mode d’emploi’, je rappelais les difficultés à faire émerger le besoin réel d’un utilisateur.
Alors en attendant la révolution des machines dans notre domaine, il faut encore passer par des analystes et des développeurs. Notre travail est d’écrire ce qui a été décrit par les analystes. Nous produisons ce que nous nommons le code. Il s’agit d’un terme générique pour indiquer les actions à réaliser. Ce code est ensuite transformé par un traitement nommé ‘compilation’ pour être compris par le processeur ou par une machine virtuelle (une interprète logiciel pour processeurs).
Le code c’est le travail des développeurs. Et le problème c’est que n’importe qui se dit informaticien (ou pire hacker) dès qu’il écrit un bout de code. Et on se retrouve avec la version sarcastique des 10 commandements du développeur.
Voici pour moi le top 10 des pires erreurs que j’ai rencontré sur du code.
| 10. | Le code compliqué. Celui qui réinvente la roue alors que la fonction ou le verbe existe déjà. J’ai vu un code de 4 pages qui pouvait être écrit en 4 lignes. |
| 9. | Les tags ‘//TODO : …‘. Le développeur ne sait pas décrire un besoin et laisse donc ce plaisir à son successeur. L’art de procrastiner. Officiellement, il s’en occupera plus tard quand il aura les informations. |
| 8. | Le code mal indenté ou non indenté. L’indentation permet de retrouver rapidement le début et la fin d’une boucle, d’une procédure, … Pas d’indentation empêche de repérer les blocs logiques d’un code, et donc de l’améliorer ou le corriger. Heureusement, il existe désormais des outils qui calcule automatiquement l’indentation. |
| 7. | Le code non commenté. Devinez ce qu’à voulu faire le développeur à l’origine du programme. Cela nécessite de réécrire l’algorithme pour trouver l’erreur. |
| 6. | Les noms de variables incompréhensible. Il y a l’erreur de débutant qui consiste à appeler ses variables ‘a’, ‘b’ et ‘i’. Cette erreur vient de l’époque où l’espace de stockage était limité. Mais de nos jours, c’est ridicule. Mais le pire est le développeur qui utilise des noms de variables incompréhensibles ou/et en ‘Leet speak’ pour se rendre indispensable dans le projet. |
| 5. | Le code non optimisé. Tout est instantané en informatique ! Non, il y a des coûts. Temps de traitement, coûts réseaux, … Oublier cela c’est condamner l’utilisateur à attendre. |
| 4. | Le code non fractionné en procédures et en fonctions. Juste une suite de milliers de lignes d’instructions. Souvent lié à la pire erreur de code, cette pratique est pourtant interdite par les enseignants en informatique |
| 3. | L’oubli de supprimer les objets lorsqu’ils ne sont plus utilisés. Bien sûr, il existe dans les langages des ‘garbage collectors’. Il s’agit de traitements qui font le ménage. À condition qu’il sachent que l’objet doit être détruit. Sinon, le programme devient une bombe logique. |
| 2. | Le fameux ‘Çà compile donc çà marche !!!’. La preuve qu’un code est correct n’est pas sa compilation. C’est surtout la preuve que celui qui dit cela est un feignant qui laissera aux autres assumer ses erreurs. |
| 1. | Le copier/coller. Je plaisante en disant que cela mérite la peine de mort mais je ne compte plus le temps perdu à cause de cette pratique. Si deux codes se ressemblent, il doit être factorisé dans une fonction. |
Il y a bien d’autres erreurs. Mais c’est déjà assez pénible de me remémorer de mauvais codes et d’être comparé à leurs auteurs parce que je suis aussi un développeur.
Pour faire le parallèle avec le monde réel, c’est comme lorsque vous allez chez le garagiste. Il y a celui qui fera l’entretien de votre voiture au juste prix, et celui qui vous ruinera avant de transformer votre voiture en épave.