Conventions de nommage (Naming Conventions)

Quel est le sujet de ce fil

Attention : Banalités Inside pour cette introduction.

Malgré tous les modèles et paradigmes apportés par un langage, dont évidement Ada, une chose fondamentale restera toujours le bon nommage des choses, ne serait‑ce que parce que le texte d’un programme est d’abord écrit, et qu’il est une série de symboles, dont on attend des qualités propres.

Ce sujet est donc ouvert et mis en post‑it (*), pour en souligner l’importance. Il n’y a pas encore foule dans cette section, et j’espère que ce sujet qui est abordable pour tout le monde, incitera quelques personnes de passage à s’inscrire et à participer à la section Ada de ce forum.

Comme je suis seul pour l’instant ici, à parler de Ada, je présenterai ma propre convention de nommage, toujours à l’état d’élaboration (élaboration mise en sommeil un temps et réveillée récemment), de mon propre point de vue, message par message. Si d’autres personnes ont des idées suffisamment arrêtées sur la question, il sera possible d’ouvrir un fil pour chaque ensemble de conventions de nommage. Il est en effet vain d’imposer un point de vue issue d’un ensemble de conventions dans un autre ensemble, la cohérence de tout ensemble de conventions, étant la clé de sa pertinence. Pour préserver les cohérences d’ensemble, si les commentaires diverges beaucoup des conventions présentés dans ce fil, et se montre incompatibles avec celles‑ci, alors autant de fils individuels que nécessaire, seront ouverts.

(*) “Post‑it” = « Sujet Épinglé ».

Critères attendus pour ces conventions de nommage

La convention de nommage que je tente de mettre en place doit répondre à quelques critères, qui comme souvent, pourront être contradictoires entre eux, et qu’il pourra être nécessaire d’arbitrer.

L’esprit de ces critères :

• Une convention aussi prévisible que possible pour les grandes abstractions. Il ne s’agit évidemment pas ici de créer une convention de nommage pour des objets concrets, ceci étant l’affaire du dictionnaire spécifique à un domaine. Si ça ne semble pas clair, ça le sera plus tard Sinon, il est possible de le comprendre en gros comme le nommage des Design Patterns.
• Des noms aussi courts que possible. Même si Ada est naturellement verbeux, plus que d’autres langages et est même redondant (par d’inférence de type, rappel de la signature d’un sous‑programme dans une clause de renommage, etc), et que ce sont des qualités, les abus sont toujours négatifs et font même mauvaise impressions sur les débutant(e)s, ce qui est assez grave, rien que pour cette raison.
• Réduire à la charge cognitive nécessaire à la lecture et à la compréhension du texte d’un programme. Ce point résume en fait la raison d’être des deux précédents.
• Pouvoir être applicable de manière aussi automatique que possible. Même si le style est important dans le texte d’un programme, ce n’est pas un exercice de littérature. Le texte d’un programme ne s’écrit pas comme un texte littéraire, et si l’imagination doit s’exprimer, ce n’est pas par sa capacité à produire des synonyme qu’elle doit le faire.

Cette rapide présentation du sujet étant faite, suit juste après le premier élément de ces conventions de nommage.