Relecture de code OCaml

Pour Natacha qui se pose la question de comment traduire code review, je dirais simplement « relecture de code ».

D’ailleurs j’en fais pas mal en ce moment, de la relecture de code, mais pas vraiment dans le contexte de participer à la qualité des logiciels libres. J’assure des TDs et TPs de programmation niveau L3 avec comme support le langage OCaml. Entre la correction des DMs et des TPs, je passe des heures à lire des lignes de code et à me demander dans quel univers parallèle au nôtre elles pourraient être correctes et répondre adéquatement à la question; parfois l’exécution du code rendu me laisse perplexe devant la constatation que cet univers parallèle pourrait être le nôtre. Le style ne faisant (hélas ?) pas encore complètement parti de nos critères de notations je me vois alors contraint de donner les points à un truc illisible tombé en marche par la seule grâce de Cthulhu.

Mais pour améliorer l’enseignement les années suivantes et encourager de saines pratiques de programmation, j’ai compilé une liste non exhaustive de conseils (qui pourraient devenir des consignes plus ou moins strictes) à l’usage de qui programme en OCaml:

1. Si votre fonction fait plus de 3 lignes et que vous ne l’avez pas commentée, vous n’auriez sans doute pas dû l’écrire.
2. Si votre fonction fait trois ou quatre lignes, la proba est d’au moins 42% pour qu’elle se réécrirait de façon plus lisible et concise par l’utilisation adéquate de List.map, List.fold_left, List.mem ou autres fonctions de base de la bibliothèque standard.
3. Si vous n’avez pas l’url précédente dans les signets de votre navigateur je ne comprends pas comment vous pouvez vous en sortir.
4. Il est très facile d’utiliser le mode d’interprétation tuareg dans Emacs de façon incorrecte en interprétant de façon anarchique diverses portions de votre fichier. En cas de doute, le mode compilé est La Seule et Unique Vérité.
5. Aucun de ces conseils ne saurait s’appliquer au corps enseignant, réputé infaillible, y compris ce conseil.