Les caractéristiques du langage Pascal

Définition du Petit Larousse : Suite finie d'opérations élémentaires constituant un schéma de calcul ou de résolution d'un problème.

Plus banalement, on appelle Algorithme toute suite d'opération, décrites par un programme ou tout bonnement griffonnées sur une feuille de papier, dont le but est de résoudre un problème. On peut dire qu'il s'agit de la description logique d'un programme.

On rattache à l'algorithmie (et pas algorythmie : on n'est pas dans un orchestre !) tous les schémas que vous avez pu voir un jour ou l'autre, et qui portent le nom d'organigramme ou d'ordinogramme. En voici un exemple :

Si vous avez un rapport argumenté à produire, vous pouvez vous amuser à faire ce genre de schéma, sinon une feuille de papier et un crayon suffiront.

Le but de notre algorithme est de bien mettre à plat toutes les étapes nécessaires à la résolution d'un problème. Il n'a en lui-même pas forcément de concrétisation matérielle : on parle d'algorithme, mais on ne l'écrit pas forcément ! Tout ça pour dire qu'un programme bien écrit et bien commenté se suffit à lui-même pour être compréhensible.

Attrapez votre souris, regardez brièvement l'exemple un peu plus bas et revenez ici. C'est bon ?
Dans cet exemple, le problème posé est d'écrire une fonction qui doit cherche dans une liste un objet à partir de son nom, et nous retourner un pointeur vers cet objet. La routine doit accepter un paramètre pour soit ne rien renvoyer, soit générer une erreur (exception) si l'item n'est pas trouvé.

Et là, je m'excuse bien bas auprès des puriste, cet organigramme n'a rien d'"officiel", il manque le début et la fin, etc. L'idée est simplement d'avoir un exemple sous la main.

Ce qu'on cherche à faire, c'est rendre notre code source facile à analyser (pour un humain s'entend). On parle beaucoup de la "maintenabilité" des programmes, qui consiste à trouver le meilleur moyen de pouvoir modifier facilement un programme après coup. Cette maintenabilité intervient aussi lors de l'écriture, bien avant que le programme soit terminé. Il est très difficile, pour ne pas dire impossible de garder dans la tête l'intégralité des algorithmes et principes utilisés dès lors d'un programme s'étoffe (en tout cas de manière précise). Le programmeur a ceci de particulier que lorsqu'il se replonge dans un programme sur lequel il n'a pas travaillé depuis plusieurs mois, il est comme un martien qui descend sur terre et il a tout à réapprendre. Ne négligez jamais la forme (je sais c'est dur !). Mettez des commentaires, indentez et surtout structurez correctement. La partie la plus difficile étant de trouver la structure la plus efficace pour votre programme, sans être trop astucieux (des astuces dont vous vous poseriez la question de l'utilité après coup). En un mot comme en cent, voici quelques maximes à afficher au plafond de votre chambre :

Être clair pour être rigoureux
Soyez clair et pas trop astucieux
Soyez rigoureux avant d'optimiser
Restez rigoureux en optimisant
Soyez clair avant d'optimiser
Restez simple pour optimiser

Écrire pour être lu
Polissez la forme pour aider le lecteur
Écrivez pour être lu de haut en bas
Commentez le code sans le trahir
Évitez l'excès de commentaires
Personnalisez et initialisez chaque variable

Être cartésien
Écrivez en clair un premier programme
Décomposez-le en blocs
Cantonnez chaque bloc à une action bien faite
Éclairez les liaisons entre bloc
Indentez pour exhiber la structure logique.

Comme il est dit plus haut, la mise d'un code source est extrêmement importante. Il existe plus ou moins des normes de fait issues de l'expérience des programmeurs et utilisées avec quelques variantes par la majorité d'entre eux. N'oubliez pas qu'il s'agit de préférences personnelles, et que rien ne vous oblige à les utiliser telles quelles. Simplement, vous aurez comme tout le monde un style de présentation probablement différent au début, qui évoluera avec l'expérience pour atteindre quelque chose qui ressemblera certainement fort à ce que je vous présente ici, mais nul n'étant prophète en son pays... et puis les goûts et les couleurs, hein...

En tout cas, voici une exemple type d'une fonction qui pourrait être prélevée dans une unité :

Vous avez pu constater que l'éditeur (EDI) de Delphi ou de Turbo Pascal met en valeur par du gras ou des couleurs les mots-clés, commentaires ou autre. Sachez que ces couleurs sont entièrement configurable : à vous de choisir celle qui vous convient le mieux. Je vous suggère d'ailleurs d'aller modifier ce paramétrage pour mettre en valeur les chaînes de caractères, ce qui n'est pas le cas avec la configuration par défaut (dans Delphi 4 : Aller dans le menu Outil/Options d'environnement, puis choisir l'onglet Couleurs).

Les majuscules

Il est d'usage d'écrire le code en minuscule et d'utiliser les majuscules pour la rendre plus compréhensibles les noms. Dans notre exemple, le nom de la fonction est FindItem, la variable MustExist, etc.

Retour à la ligne, begin et end :

D'une manière générale, on ne met jamais plus d'une instruction par ligne (un seul point-virgule), et on effectue un retour à la ligne après un then. Néanmoins, pour ne pas trop rallonger un code trop long, ou pour rendre plus clair sa structure, il est possible de ne pas effectuer ce retour quand la ligne reste très courte.

  if not Updated then Update; I := IndexOf(Name);

if not Updated then Update;

ou (préférable)

if not Updated then Update;

Quand au begin et au end, je positionne mes begin sur la même ligne que le else parce que ça raccourci la longueur du texte, mais attention aux oublis !. d'autres préfèrent aligner verticalement systématiquement les begin et les end.

begin
  if ... then
    ...
  

      else 
  begin
      

      ...
  end;
end;

begin if ... then ... else begin ... end; end;

Les noms de variable

N'hésitez pas à fournir des noms de variable compréhensibles. Ne soyez pas fainéants, mais n'en abusez pas ! Si vous avez par exemple une variable qui désigne le numéro de la couleur maximum dans un tableau, évitez NumeroDelaCouleurMaximum. NumeroCouleurMaximum est peut-être encore trop long. Une bonne idée serait quelque chose comme noCoulMax ou noCoulMax, ou encore NumCouleurMax.

Les commentaires

Nous en avon déjà parlé : utilisez les à bon escient. Pour ma part j'ajoute systématiquement un en-tête explicatif en début de fichier (projet, version, ...).

je répète aussi le nom de la procédure et fonction après le "end;" de fin ( end; {FindItem} ). Celà permet lorsqu'on est en bas du code de savoir sur quelle procédure on travaille.