Bonnes pratiques pour l'écriture d'algorithmes


22

Il s'agit de l'efficacité avec laquelle nous pouvons exprimer un algorithme à portée de main. J'en ai besoin pour mon enseignement de premier cycle.

Je comprends qu'il n'y a pas de moyen standard d'écrire un pseudo-code. Différents auteurs suivent différentes conventions.

Il serait utile que les gens ici soulignent la façon dont ils suivent et pensent le meilleur.

Y a-t-il un livre qui traite de cela en détail?


9
"meilleur" est très subjectif, je pense que vous devriez modifier le titre et au lieu de demander "meilleur" demander ce que les gens font dans la pratique. Peut-être quelque chose comme "comment présenter des algorithmes" ou "bonnes pratiques pour présenter des algorithmes". Vous pouvez également être plus précis car présenter des algorithmes: 1. aux étudiants d'une classe de premier cycle 2. dans un manuel 3. dans un document de conférence sont des tâches très différentes.
Kaveh

1
Vous pouvez également consulter les sections pertinentes de l'écriture mathématique de Knuth, Larrabee et Roberts.
Kaveh

Réponses:


26

Écrire un pseudocode, c'est comme écrire du code: Peu importe la norme que vous suivez, tant que vous (et les personnes avec qui vous écrivez) suivez réellement une norme.

Mais pour mémoire, voici la norme idiosyncrasique que j'utilise dans mes notes de cours, mes articles de recherche et mon prochain livre.

  • Utilisez la syntaxe impérative standard pour le flux de contrôle et l'accès à la mémoire - if, while, for, return, array [index], function (arguments). Épelez «sinon si».

    • Mais utilisez au lieu de oufield(record)record.fieldrecord->field
  • Utilisez la notation mathématique standard pour les mathématiques - Écrivez au lieu de , a mod b au lieu de , s t au lieu de , ¬ p au lieu de , xyx*yamodba%bsts <= t¬p!p au lieu de,πau lieu de,au lieu de, etc.Xsqrt(x)πPIMAX_INT

    • Mais utilisez pour l'affectation, pour éviter le problème.Xy==

    • Mais évitez complètement la notation (et le pseudocode!) Si l'anglais est plus clair.

      • Symétriquement, évitez l'anglais si la notation est plus claire!
  • Minimiser le sucre syntaxique - Indiquer la structure des blocs par indentation cohérente (à la Python). Omettez les mots clés sucrés comme "début / fin" ou "do / od" ou "fi". Omettez les numéros de ligne. Ne pas mettre l' accent sur des mots clés comme « pour » ou « tout » ou « si » en les plaçant dans un autre typefaceou de style . Déjà. Mais ne le fais pas.

    • Mais composez les noms et les constantes de l'algorithme dans \ textesc {petites majuscules}, les noms des variables en italique et les chaînes littérales en sans serif.

    • Mais ajoutez une petite quantité d'espace de "respiration" vertical ( \\[0.5ex]) entre des morceaux de code significatifs.

  • Ne spécifiez pas de détails sans importance. Si l'ordre dans lequel vous visitez les sommets n'a pas d'importance, dites simplement "pour tous les sommets".

Par exemple, voici une formulation récursive de l' algorithme d'arbre couvrant minimal de Borůvka . J'ai précédemment défini comme le graphique obtenu à partir de G en contractant toutes les arêtes de l'ensemble L , et Flatten comme une sous-routine qui supprime les boucles et les arêtes parallèles.g/LgL

L'algorithme de Borůvka

J'utilise mon propre algorithmenvironnement LaTeX léger pour composer le pseudocode. (C'est juste un tabbingenvironnement à l'intérieur d'un \fbox.) Voici mon code source pour l'algorithme de Borůvka:

\begin{algorithm}
	\textul{$\textsc{Borůvka}(G)$:}\+
\\	if $G$ has no edges\+
\\		return $\varnothing$\-
\\[0.5ex]
	$L \gets \varnothing$
\\	for each vertex $v$ of $G$\+
\\		add the lightest edge incident to $v$ to $L$\-
\\[0.5ex]
	return $L \cup \textsc{Borůvka}(\textsc{Flatten}(G / L))$
\end{algorithm}

Fj(v)jthv

@SureshVenkat: C'est la façon dont vous le faites habituellement dans les langages fonctionnels, ainsi que la notation dans TAoCP. (Évidemment, je ne peux pas savoir si c'est pourquoi Jɛ ff E utilise cette notation.)
Radu GRIGore

5
La principale raison de faire attention au pseudo-code est qu'il est facile de se tromper sur l'algorithme, il est donc important de souligner certaines choses. L'exemple de Jeff ci-dessus pour Boruvka illustre cela. Dans le code L est traité comme un ensemble. Un bord uv peut être le bord le plus léger incident à u ainsi qu'à v, il est donc ajouté deux fois dans la boucle, mais peu importe si vous considérez L comme un ensemble. Cependant, ce n'est pas évident et quelqu'un qui l'implémente peut facilement être déclenché s'il implémente L en tant que liste.
Chandra Chekuri

2
@ChandraChekuri: Oui, l'implémentation incorrecte des ensembles peut entraîner des problèmes dans les algorithmes qui manipulent les ensembles.
Jeffε

1
@SureshVenkat: Oh, ça. Non, je ne peux pas le supporter. Des mots clés en gras font pleurer l'enfant Jésus. Dijkstra devrait perdre son prix Turing pour avoir introduit cette convention typographique exécrable.
Jeffε

11

J'ai tendance à utiliser quelque chose qui ressemble à la syntaxe Python. Python est déjà assez proche du pseudocode que, dans certains cas, mon pseudocode peut devenir un code de travail réel.


Moi aussi, mais en Ruby. Avec gistub gists, vous pouvez facilement partager des extraits exécutables avec lesquels ils peuvent jouer. gist.github.com/chadbrewbaker/7202412
Chad Brewbaker

Python n'est cependant pas bon pour représenter l'algèbre linéaire. Octave est un meilleur ajustement je pense dans ce cas (plus proche du pseudocode).
généreux

3

Si vous voulez avoir un code défini (c'est-à-dire peu ou pas de mathématiques, proche de la vraie programmation), vous voudrez peut-être envisager d'avoir du code qui compile réellement. Cela présente plusieurs avantages:

  • Vous obtenez la coloration syntaxique partout.
  • Le compilateur vérifie la syntaxe pour vous et applique la cohérence.
  • Vous pouvez tester vos implémentations à l'unité pour améliorer la qualité du code.
  • Vous pouvez exécuter l'algorithme et comparer les durées d'exécution mesurées aux analyses (motivant ainsi des techniques d'analyse avancées).

Un professeur de mon université le fait dans son cours d'algorithmes. Sa langue de prédilection est Modula. Mais je ne pense pas que le choix particulier de la langue compte. Restez-en à un (par paradigme) qui correspond le mieux à votre niveau d'abstraction.


"Il suffit de s'en tenir à un (par paradigme) qui correspond le mieux à votre niveau d'abstraction." Je pense que c'est un excellent conseil pour trouver une alternative au pseudocode. Il existe de nombreux langages, et presque toujours il y en a au moins un qui cible une syntaxe simple pour un paradigme spécifique: Ada pour la conception simultanée, Octave pour l'algèbre linéaire, Python pour la procédure, NetLogo pour les systèmes multi-agents, Prolog pour la logique, CLIPS pour programmation basée sur des règles, etc.
génial

@gaborous Si vous pouvez avoir un code lisible et abstrait - allez-y. Malheureusement, je soupçonne que cela vous obligera à utiliser au moins trois langues dans un ensemble de travaux plus vaste; ce serait dommage aussi.
Raphael

bien sûr, je suis d'accord pour que le code soit plus grand, il n'y a pas de langage, mais pour les petits algorithmes de base, il est souvent possible de trouver un langage très proche du pseudocode.
génial
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.