Styles

dimanche 6 juillet 2008

Goto implicites et structures de données

Qu’est-ce qu’on reproche à ce fameux GOTO ? D’être indiscipliné ? De semer l’anarchie dans le code source ? Oui, c’est vrai qu’il nous ramène en plein moyen-âge informatique, à une époque où on connaissait à peine la notion de routine. Aujourd’hui, il est rare de trouver explicitement des GOTO dans du code. Il y a eu et il y a toujours beaucoup de bruit autour de l'emploi du GOTO, mais franchement, la hache de guerre est depuis longtemps enterrée.

Mais est-ce qu’implicitement il n’y aurait pas des sortes de GOTO qui se cachent discrètement dans mon code ?

Les structures des données traitées par un programme, contraignent les algorithmes chargés de leur manipulation. L’utilisation de tableaux indexés contraint très peu les algorithmes, ce qui fait qu’il peu exister une organisation implicite, non visible des données contenues par un tableau.

Un programmeur sera donc tenté d'accéder directement à n'importe quel élément du tableau et ainsi, reproduit au niveau du code un flux de traitement non séquentiel, voire même aléatoire : un peu comme des GOTO !

Ainsi, des sortes de GOTO implicites mais bien présents (par exemple, l’inflation du nombre de if(), de switch() et de break sans parler des IF arithmétique qu'affectionne les programmeur en Fortran) dans les algorithmes peuvent être employés pour gérer les données d’un tableau.

Comment s’assurer que les développeurs d’un logiciel ne se mettent pas disséminer des GOTO implicites ? En leur interdisant d’utiliser des tableaux indexé et en les obligeant à employer de véritables conteneurs comme les ensembles (Sets), les piles (Stacks) et les files d’attentes (Queues). Ces conteneurs obligent à accéder de façon séquentielle à leurs éléments et évitent ainsi l’introduction de GOTO implicites.

A éviter donc toutes les méthodes du type Collection.toArray()... ces méthodes ont l'inconvénient d'exposer partiellement l'implémentation, de dénaturer la collection en question.

Ce qui nous ramène donc à l'analyse statique du code, avec les outils classiques que sont les outils OpenSource FindBugs et PMD pour le monde Java, mais aussi commerciaux comme le puissant Polyspace que j'ai utilisé une fois sur un projet, ou d'autres. Il n'existe pas de règles déjà définit pour empêcher l'utilisation de tableau bien que de nombreuses règles portent sur le mauvais emploi des tableaux à travers les classes.

Alors, prêt à jouer les dictateurs et empêcher tout emploi de tableau indexé ? Allez... j'accepterai peut-être un Array si c'est correctement justifié :) mais alors, je considerai ça comme un nouvelle dette technique.

Aucun commentaire: