ans le précédent article nous avons vu quelques règles de programmation, elles portaient plus sur le style, la forme que le fond. Nous allons en étudié d'autres qui elles impactent plus sur l'efficacité réelle des programmes. Ces règles sont applicables à tous les développements qu'ils soient ou non sur le web.

Que l'on soit bien d'accord, ce sont des règles que je me fixe, je sais que je ne les applique pas à 100% :-))) ; je le paie toujours, mais il est trop tard. On a (j'ai) toujours de bonnes raisons pour faire l'impasse sur certaines d'entre elles, la plus fréquemment invoquée est sans doute le temps, les délais sont parfois brefs.Mais, quand il faut revenir dessus on paie les hypothèques. A la longue, certaines d'entre elles deviennent naturelles et nous n'avons pas nos repères quand elles n'ont pas été appliquées.

Voici quelques-unes des règles que j'applique, en vrac

• Réfléchissons d'abord et programmons plus tard, cela paraît une lapalissade, mais quand on commence à écrire le code avant que le problème soit bien posé, ce dernier ne peut pas être bien résolu.
  
  
• Soignons l'usage de variables intermédiaires presque tous les langages permettent de construire en une séquence des expressions complexes. Mais pour des raisons de clarté il est souvent avantageux de les couper en utilisant des variables intermédiaires. Pour ma part, je commence par utiliser des variables intermédiaires et quand tout est au point, je regroupe. Le regroupement est parfois nécessaire pour éviter l'inflation du nombre de ces variables intermédiaires.
  
  
• Ne recalculons pas les constantes de boucle, quand une expression intervient dans une boucle mais que sa valeur ne change pas, affectons-la à une variable intermédiaire que nous utilisons dans le corps de la boucle. On voit fréquemment une boucle sur un tableau dont la borne de fin est son nombre d'éléments, il est abberrant d'écrire for(i=0; i<nbelt(tab); i++). C'est l'exemple le plus typique.
  
  
• Utilisons l'indentation dans les structures de contrôle. Cela met bien en valeur les débuts et fins de boucle, de si-finsi etc... J'ai même vu quelqu'un récemment qui mettait en commentaire sur la ligne fin de boucle le rappel du test qui était en début de boucle, cela m'a plu, je l'ai ajouté à ma panoplie de style.
  
  
• Soignons la syntaxe, même si le langage tolère des oublis, écrivons le code dans sa meilleure syntaxe. Nous ne sommes jamais à l'abri d'une erreur nous l'avons tous appris à nos dépends, alors faisons des efforts pour bien écrire aussitôt.
  
  
• Evitons les particularités des implémentations, un bon exemple, je me méfie comme de la peste de l'ordre des évaluations et pour ne pas être constamment obligé d'étudier les priorités je parenthèse beaucoup mes expressions. Je reconnais quand même que les priorités entre opérateurs sont globalement proches, je n'ai pas fait d'étude comparatives sur le sujet. Je préfère tout simplement ne pas avoir à me poser de questions ; cela rend l'expression plus lisible à mon avis.
  
  
• N'ayez pas peur de tout recommencer, parfois parce que les spécifications ont beaucoup évoluées au fil du développement, le(s) programmes sont illisibles, il vaut mieux alors tout reprendre à zéro. Ce que je viens d'écrire est en contradiction avec "Réfléchissons avant de programmer", mais, encore plus sur le net, l'utilisateur découvre qu'il peut avoir un peu plus qu'imaginé au début, mais comme en interne ce n'est pas trop compatible on fait des verrues etc.. C'est tout le compromis entre une conception béton qui va prendre des mois et du développement rapide. On entre dans le développement itératif, il faut accepter alors de devoir réécrire des pans entiers de l'application pour la rendre plus modulaire par exemple..
  Pour lire la première partie.

Daniel Lucazeau
@jornet.com
Chef de projet Internet
Développeur informatique

Tous droits réservés - Reproduction même partielle interdite sans autorisation préalable