Pascal - Algorithmique

---

De l'Algorithme ou de l'art de ne pas être trop astucieux

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.

Ce mot est à connaître et à placer régulièrement dans les conversations !

Plus banalement, on appelle Algorithme toute suite d'opérations, 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 chercher 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é.

L'algorithme est :

Et là, je m'excuse bien bas auprès des puristes, 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 en tête l'intégralité des algorithmes et principes utilisés dès lors qu'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.

Metteur en forme

Comme il est dit plus haut, la mise en forme 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 configurables : à 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 minuscules et d'utiliser les majuscules pour rendre les noms plus compréhensibles. 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.

JAMAIS ça :

Exemples possibles :

Quant au begin et au end, je positionne mes begin sur la même ligne que le else parce que ça raccourcit la longueur du texte, mais attention aux oublis ! D'autres préfèrent aligner verticalement systématiquement les begin et les 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 avons 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} ). Cela permet lorsqu'on est en bas du code de savoir sur quelle procédure on travaille.

Article écrit par Thierry Cornu

Trucs & astuces pertinents trouvés dans la base de connaissances

03/06 00h46	Liens Compilateurs et Ressources (Pascal)
Plus d'astuces sur « algorithmique pascal »

Discussions pertinentes trouvées dans le forum

10/10 15h51	algorithmique	Développement	20/01 22h40->ibrahim ahma...	8
07/04 21h38	probléme en algorithmique	Développement	26/04 16h51->mohamed	7
07/03 11h55	algorithmique	Développement	14/07 04h25->Lupin.Arsene	5
19/09 22h41	Arbre algorithmique HELP !!!	Développement	21/09 21h02->ganesh59	5
05/06 11h28	schema algorithmique ???	Développement	13/11 13h40->alexandra	4
23/03 14h54	Recherche d'aide en algorithmique	Développement	23/03 18h15->random	3
27/04 12h09	Algorithmique	Développement	27/04 12h18->sebsauvage	2
19/01 16h48	cours algorithmique	Développement	12/02 18h21->djamel hichem	2
12/12 14h43	algorithmique debutant ( pour langage C	Développement	10/09 22h17->hicham	2
Discussion fermée Problème résolu		Plus de discussions sur « algorithmique pascal »

Ce document intitulé « Pascal - Algorithmique » issu de l'encyclopédie informatique Comment Ça Marche (www.commentcamarche.net) est mis à disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixées par la licence, tant que cette note apparaît clairement.