Il semble difficile de déterminer si un programme est lisible quand on ne sait pas qui et quelles sont les qualifications de la personne qui va le lire. Le plus souvent on ne connait pas cette personne a priori. Au moment de la création initiale du logiciel, on n'a pas encore choisi la ou les personne(s) qui maintiendront le programme.
Pour compliquer encore la maintenance du logiciel, les créateurs initiaux du programme ont souvent changé de poste ou d'entreprise quand le logiciel arrive en phase de maintenance. Ceci est dû à la rotation habituelle du personnel dans le secteur du logiciel. Il est relativement rare qu'un développeur reste plus de quatre à cinq ans dans la même société.
Dans ces conditions, comment déterminer des règles universelles pour une programmation lisible?
La réponse s'appelle la culture partagée des développeurs. En fait, tout développeur doit avoir une formation de base commune. Cette formation est partiellement donnée sous la forme d'unités d'enseignement enseignées à l'université ou dans les écoles d'ingénieurs. Mais la formation universitaire n'est pas suffisante pour créer une culture partagée par les développeurs de logiciels.
Pour le comprendre, faisons la comparaison entre un développeur et un artiste (un écrivain par exemple). Les deux sont en fait assez similaires. La formation d'un écrivain comprend la langue utilisée pour écrire les oeuvres, différentes façons de développer une histoire et ses personnages, etc. Mais un livre écrit par un écrivain ayant seulement suivi ces formations serait probablement assez mauvais. La formation de l'écrivain est complétée par une lecture régulière de livres d'autres auteurs, souvent des dizaines de livres par an.
Il en est de même pour un développeur de logiciels. Sa formation initiale comprend un ou plusieurs langages de programmation, la façon d'organiser les instructions pour obtenir des programmes efficaces (théorie algorithmique), ainsi que des règles de base nécessaires pour la maintenabilité et la réutilisabilité. Mais comme dans le cas d'un écrivain, un programme écrit par un développeur ayant seulement suivi ces formations serait probablement assez mauvais. La formation du développeur doit être complétée par la lecture régulière de programmes écrits par des développeurs experts, de préférence des dizaines par an, de préférence utilisant différents langages de programmation.
De cette façon, il est possible de créer une culture partagée, une façon de s'exprimer commune à l'ensemble des développeurs. Une grande partie de cette culture sera constituée de ce que nous appelons idiomes de programmation. Pour expliquer ce qu'est un idiome de programmation, il est encore utile de regarder la comparaison avec les langues naturelles. La grammaire d'une langue comme le français, détermine (par définition) si une phrase est grammaticale ou non. Mais ce n'est pas parce qu'une phrase est grammaticale qu'elle est idiomatique, à savoir réellement utilisée par les locuteurs de cette langue. Il y a beaucoup moins de phrases utilisées que de phrases grammaticales possibles. De plus, les phrases utilisées dépendent fortement de la langue en question. Par exemple, pour dire ``j'ai faim'' en Anglais, on dit ``I am hungry''. Bien que la phrase ``I have hunger'' (la traduction immédiate de ``j'ai faim'') soit grammaticale, elle n'est pas idiomatique. C'est aussi le cas de la phrase ``je suis affamé'', qui n'exprime pas la même chose que la phrase ``I am hungry'', alors que c'est sa traduction litérale.
La programmation aussi a ses idiomes, à savoir des phrases réellement utilisées par les développeurs. Ce n'est pas parce qu'une phrase (une instruction dans un langage de programmation) est grammaticale (correcte d'après les règles du langage) qu'elle est idiomatique. Pour produire un programme lisible, le programmeur doit donc éviter des instructions non idiomatiques.
Exemple : pour exprimer une boucle qui sera exécutée 
fois en
langage C, on écrit toujours une phrase comme :
for (i = 0; i < n; i++) ...
Une faute fréquente par des débutants en langage C est de l'écrire comme ceci :
for (i = 1; i <= n; i = i + 1) ...
Le résultat est le même (sous certaines restrictions), mais la deuxième phrase n'est pas idiomatique. D'ailleurs, le lecteur expert de cette phrase constate immédiatement un ``accent étranger''; il soupçonne que le langage ``maternel'' de l'auteur est Pascal ou Fortran.