Introduction à la «bonne» programmation

Nous devons changer notre attitude traditionnelle envers la construction des programmes :
au lieu de considérer que notre tâche principale est de dire à un ordinateur ce qu'il doit faire,
appliquons-nous plutôt à expliquer à des êtres humains ce que nous voulons que l'ordinateur fasse.

Celui qui pratique la programmation lettrée peut être vu comme un essayiste, qui s'attache principalement à exposer son sujet dans un style visant à l'excellence.
Tel un auteur, il choisit, avec soin, le dictionnaire à la main, les noms de ses variables et en explique la signification pour chacune d'elles.
Il cherche donc à obtenir un programme compréhensible parce que ses concepts sont présentés dans le meilleur ordre possible.
Pour cela, il utilise un mélange de méthodes formelles et informelles qui se complètent. »

— Donald KNUTH, « Literate Programming » —

Et comme disait Albert CAMUS : « Mal nommer un objet, c'est ajouter au malheur de ce monde. »
Il ne savait pas à l'époque à quel point cela pourrait déstabiliser un programmeur peu scrupuleux
lors du choix de ses noms de variables ou de méthodes ...

Vous devez donc toujours être capable de justifier vos choix de noms de variable autrement que par un « Pourquoi pas ? »

Et vous devez modifier vos noms de méthode quand elles changent de comportement, par exemple :
- setExit positionne une sortie, alors que setExits en positionne plusieurs.
- setItem positionne le seul objet qui peut l'être, alors que addItem ajoute un objet là où il peut y en avoir plusieurs.