Conception d'un programme

a. Règle : 1 notion = 1 variable

Lorsque vous listez les informations nécessaires pour effectuer un traitement, vous listez, sans vous en rendre compte, les variables dont vous avez besoin. Vous devez donc respecter la règle suivante :

Prenons un exemple. Si vous devez créer un clone du jeu PacMan, il va falloir afficher les différents éléments du jeu à l’écran. Pour cela, il faut connaître la position de PacMan, des quatre fantômes et des bonus. Ainsi, pour avoir ces informations à disposition, il est nécessaire de créer des variables pour stocker les positions des éléments du jeu comme xPacMan et yPacMan…

Lorsque l’on affirme que chaque notion doit être représentée par une variable, cela sous-entend qu’il ne faut pas en choisir zéro ou plusieurs !

Dans le premier cas, l’absence de variable se produit lorsqu’un programmeur écrit un calcul à l’intérieur d’un autre traitement, comme dans l’exemple suivant :

if 0 < x + cos(theta) * y - 400 < 217 : 

Ce code est évidemment peu lisible car il est très difficile de déterminer la signification du test effectué. Par contre, en créant une variable Xecran (correspondant à une coordonnée écran issue du calcul x + cos(theta) * y - 400) et une variable LARG_AFF (correspondant à la largeur de la zone d’affichage), on obtient :

# coordonnée du héros à l'écran 
Xecran   = x + cos(theta) * y - 400 
 
# largeur de la zone d'affichage 
LARG_AFF = 217  
 
if 0 < Xecran < LARG_AFF :  # teste si héros visible à l'écran 

Le second cas où plusieurs variables existent pour décrire une même notion semble peu concevable. Pourtant, cette situation peut se produire, en voici un exemple. Pour gérer un ensemble d’éléments, un programmeur peut décider de créer une variable NbElem indiquant le nombre d’éléments dans l’ensemble et une autre variable EstVide indiquant si cet ensemble est vide. Techniquement, ce programme peut fonctionner avec ce choix de conception. Cependant, la variable EstVide est en redondance avec la variable NbElem. Ainsi, chaque fois que le nombre d’éléments change, la variable NbElem est modifiée. Mais il faut aussi penser à mettre à jour la variable EstVide, et le risque d’oublier cette variable secondaire existe. Ce choix de conception est dangereux, mieux vaut choisir une unique variable pour stocker la quantité d’éléments présents et recalculer à la volée le test permettant de déterminer si aucun élément n’est présent.

b. Identifier une variable par la présence de code répétitif

Vous avez sûrement déjà rencontré du code ressemblant à l’exemple suivant :

if Tab[k][j] == 1 :  
   ..  
elif Tab[k][j] == 0 or Tab[k][j] == 4 :  
   ...  
elif Tab[k][j]...

a. Prérequis

Si vous avez le choix entre mettre en place une fonction ou copier-coller du code existant pour l’adapter, la tentation du copier-coller sera forte. Voici pourquoi :

b. Analyser ou restructurer le code

Deux approches existent :

Quelle que soit l’approche choisie, étude sur papier ou codage direct, il faudra dans tous les cas que vous sachiez faire évoluer la structure de votre code. Nous allons donc nous mettre dans la situation où beaucoup de lignes de code ont été écrites et où il faut maintenant essayer de les structurer pour remodeler le programme convenablement.

c. La mauvaise approche

On peut écrire de nombreuses lignes de code les unes à la suite des autres sans appels de fonctions. Lorsque l’on veut structurer le code existant, le mauvais réflexe consiste à sélectionner, un peu au hasard, des portions de code pour les transformer en fonctions. Cette approche apporte plusieurs satisfactions à court terme :

Voici un exemple avec un programme de cinq lignes :

Ligne1 
Ligne2 
Ligne3  
Ligne4 
Ligne5 

Le programme est restructuré en fonctions de la manière suivante :

En faisant ces choix à tâtons, il faut être conscient qu’une multitude de possibilités existent. Ainsi, on peut produire de très nombreuses configurations...

a. Du point de vue du débutant

Si vous mettez en place un projet important en juxtaposant des morceaux de code et en espérant que cela se passe bien, malheureusement, cela ne va pas bien se passer. En effet, cette approche induit un manque d’organisation et une absence de structure dans votre projet. Ce dernier finira par ressembler à une pieuvre tentaculaire, les bugs que vous rencontrerez seront très difficiles à corriger et faire évoluer votre programme vous semblera une tâche insurmontable.

Tom va essayer de mettre en place des choix de conception, de découper son projet en parties indépendantes, de représenter les données de la manière la plus adéquate possible et de ne pas mélanger les différents niveaux de hiérarchie dans son programme. Tom aura beaucoup de bonnes idées, mais il s’apercevra que beaucoup de zones d’ombre restent présentes même en ayant déjà passé beaucoup de temps à repérer les pièges. Il devra donc repenser son modèle de conception, essayer de l’améliorer sans pour autant choisir une solution trop complexe pour son niveau.

À certains moments, Tom devra faire appel à son ami Benjamin pour des problèmes qui le dépassent. En effet, parfois, il est très difficile de trouver l’origine d’une erreur, même si le code semble simple et écrit correctement. Un avis externe lui sera nécessaire.

Ce chapitre original présente la construction d’un jeu plutôt simple mais relativement long, ceci par un programmeur débutant ou expérimenté. Beaucoup de débutants croient qu’il faut avoir la bonne intuition dès le premier instant. Dans le cas contraire, ils concluent que l’on n’est pas fait pour devenir un bon développeur. D’autres pensent qu’il faut s’attacher à tout prix à leur idée de départ même si celle-ci s’avère peu concluante. En bref, ces comportements sont trop extrêmes. En suivant la progression de Tom, vous allez comprendre qu’on ne peut pas connaître tous les pièges avant d’avoir commencé. Pourtant, dans beaucoup de formations IT, on vous explique qu’il faut rédiger un descriptif complet de l’application et la programmer ensuite, comme ferait un architecte pour une maison. Si vous êtes débutant ou si vous êtes expérimenté et que vous vous attaquez à un programme sortant de vos habitudes, il faut accepter l’idée que des étapes...