Bloc-notes

1. Il y a plusieurs manières de le faire.

On a montré précédemment comment écrire en Perl une instruction qui vérifie qu'une variable contient un numéro de téléphone français valide, c'est à dire une série de 10 chiffres séparés éventuellement par des espaces ou des tirets :

Version 1 :

  // vérifie si la ligne est à peu près de la forme nn-nn-nn-nn-nn
  // où nn est un nombre de deux chiffres
  die "$_ n'est pas un numéro de téléphone valide !"
    unless /^((\d){2}[ \.-]?){4}(\d){2}$/;

Or il y a de nombreuses manières de réaliser cette vérification. C'est particulièrement vrai avec le langage Perl, dont la devise est TIMTOWTDI, ce qui signifie : « There is more than one way to do it ». Ainsi le code suivant est exactement équivalent :

Version 2 :

  my $nb_tel = $_;
  unless($nb_tel =~ /^
          ( (\d){2} # deux chiffres...
            [ \.-]? # suivis peut-être d'un tiret, point ou espace
          ){4}      # le tout répété 4 fois...
          (\d){2}   # avec ensuite deux chiffres
          $/x) 
  {
    # Si $nb_tel ne respecte pas les règles des numéros de 
    # téléphone français, on renvoit une erreur
    die "$nb_tel n'est pas un numéro de téléphone valide !";
  }

L'algorithme utilisé est exactement le même. La seconde rédaction est plus claire : le second programmeur a pris soin de structurer son code et de le commenter afin de le rendre plus aisément compréhensible pour tout informaticien (y compris lui-même quelques mois plus tard) qui serait amené à intervenir sur ce programme ultérieurement.

On pourrait envisager d'autres écritures qui modifient non seulement l'apparence immédiate du programme, mais également l'algorithme qu'il utilise. L'algorithme, c'est l'ensemble des étapes et calculs internes par lesquels passe l'ordinateur, guidé par le programme, afin de vérifier que le numéro de téléphone est bien composé de cinq paires consécutives de chiffres.

Version 3 :

	 
  my $nb_tel = $_;
  my $state = 0;
  my $nbpaires = 0;
  eval {
   for my $c (split //, $nb_tel) {
      if($state == 0) {
        $nbpaires++;
        die if $nbpaires > 5;
        die unless $c =~ /\d/;
        $state = 1;
      }
      elsif($state == 1) {
        die unless $c =~ /\d/;
        $state = 2;
      }
      else {
        die unless $nbpaires <= 4;
        die unless $c =~ /[ \.-\d]/;
        $state = 0 if $c =~ /[ \.-]/;
        $state = 1, $nbpaires++ if $c =~ /\d/;
      }
    };
  };
  die "n'est pas un numéro de téléphone valide !" if $@;

Cette version est beaucoup plus longue que la première.

2. Les programmeurs ont du style.

Il y a donc plusieurs manières d'atteindre le même but. Cette possibilité de choix conduit chaque programmeur à adopter, plus ou moins consciemment, un « style » propre. Deux programmeurs différents n'écriront pas le même programme. C'est que les langages informatiques sont bien des langages : deux faits de langages par deux énonciateurs différents ne seront jamais identiques.

Or le langage informatique a deux cibles :
- une cible principale, l'ordinateur à qui le programme donne des instructions ;
- une cible secondaire, les autres programmeurs (ou le même programmeur plusieurs mois plus tard) qui auront peut-être besoin de comprendre le fonctionnement interne du programme.

Le style du programmeur joue sur ces deux cibles. D'une part le choix de l'algorithme peut avoir un effet sur les performances du programme : la version 2 et la version 3 du programme ci-dessus utilisent des algorithmes différents, donc l'ordinateur exécutera des tâches distinctes, de sorte que le temps d'exécution sera sans doute légèrement différent.

D'autre part le choix de la ponctuation et de la mise en forme a un effet sur la lisibilité du programme. La version 2 du programme comporte plus d'espaces et de commentaires que la version 1 et devrait être plus facilement compréhensible.

3. Les programmes informatiques peuvent être élégants.

Un professeur de Maths Spé, homme d'une grande valeur avec lequel les élèves passaient quatre heures tous les jours sans jamais se lasser de lui, arrivait parfois le matin en disant : « Tiens, hier soir j'ai repensé au théorème que je vous ai démontré hier et j'ai trouvé une nouvelle preuve... » La nouvelle démonstration n'était pas « meilleure » que la précédente : l'une comme l'autre suffisait à établir la validité du théorème. Sans doute atteignait-elle ce but d'une manière plus simple, ou plus concise : cela satisfaisait le sens esthétique du professeur.

De la même manière, les programmeurs sont sensibles à la dimension esthétique des programmes. Face aux trois exemples présentés ici, chacun selon son expérience, sa sensibilité, ses critères de qualité, trouvera certainement qu'une version est plus « élégante ».

Un hacker préférera peut-être la version 1, parce qu'elle remplit sa mission avec une grande économie de moyens grâce à une utilisation de fonctionnalités avancées du langage Perl. Un programmeur moins habitué au langage trouvera au contraire cette version horrible et préférera la deuxième (s'il connaît un peu les « expressions régulières ») ou la troisième (s'il a déjà réalisé des « machines d'état »). Dans un environnement où le travail en commun prime, les versions les plus lisibles et les mieux commentées auront la préférence de l'équipe, tandis que les versions concises seront présentées comme exemple sur les forums spécialisés de passionnés.

Précédent :
Fin : le programmeur et les objets.