À un niveau très simple, une discipline de programmation s'exprime souvent par des slogans. Parmi les plus connus, on trouve les suivants :
Bien décrire les structures de données.Éviter les goto (branchements).
Éviter les effets de bord.
Manipuler les pointeurs avec précaution.
Écrire les assertions.
Commenter !
Il est facile de constater que les langages de programmation ont incorporé progressivement certains de ces slogans en les «cablant» dans leur définition. Les types permettent de décrire les structures de données et la programmation objet va assez loin dans ce sens. Les structures de contrôle permettent d'éviter les goto. Ici, les langages de programmation structurée donnent un nom à certains agencements de goto. Des classes entières de langages de programmation (par exemple, fonctionnelle ou logique) ignorent le goto, et ont d'ailleurs un nombre très limité de structures de contrôle. Hors les langages de programmation fonctionnelle ou logique, beaucoup moins est fait pour limiter les effets de bord, et même ces langages ont une approche un peu timide qui se limite aux effets de bord par affectation, mais qui ne fait pas grand chose contre les effets de bord par entrée-sortie ou autres contacts avec l'environnement. Nous n'ignorons pas les travaux sur les entrées-sorties purement fonctionnelles (monades [Wadler 90]) ou purement logiques (Mercury [Somogyi et al. 96]), mais il s'agit d'un effort tardif dans le développement de ces langages, et qui nous semble n'être que marginalement exploité. Discipliner l'accès aux pointeurs est souvent fait en les supprimant (par exemple en programmation fonctionnelle et logique) ou en limitant les opérations qui s'y appliquent (le langage Java). Nous n'avons mis le dernier slogan «Commenter !» que pour marquer une sorte de limite supérieure de la possibilité de cabler une discipline dans un langage, mais l'avant-dernier slogan correspond à une sorte de formalisation des commentaires qui est prévue dans le langage Eiffel.
Il est aussi facile de constater que même si un langage de programmation
cable une discipline, il ne le fait pas souvent jusqu'au bout, ou alors il
réintroduit la chose à éviter sous une autre forme.
Par exemple, le goto coexiste souvent avec des structures de contrôle
plus élaborées
ou renaît sous la forme d'une capture de continuation.
Les effets de bord réapparaissent en 
avec les «références»
et en Prolog avec les accès en écriture à la base de données.
Il est d'autres slogans que nous ne partageons pas, qui ne sont satisfaits par aucun langage moderne, et qui nous semblent relever de la peur de la technologie. On peut les trouver dans des disciplines de programmation d'entreprise, et dans des systèmes automatiques qui vérifient qu'elles sont suivies. Les deux exemples qui suivent viennent du guide d'utilisation de l'outil «C RuleChecker» de Logiscope (produit de Verilog). Il s'agit de deux des règles de programmation livrées avec le produit et «établies à partir de normes de programmation C issues de l'industrie [et] de notre expérience en matière d'Assurance Qualité Logiciel» (citation d'après le manuel). Nous avons aussi repris la présentation des règles de ce manuel. Ces règles sont livrées avec le produit, mais l'utilisateur peut n'en sélectionner qu'une partie, les modifier et même en inventer de nouvelles.
cod_26_decl_loc : Déclaration de variables locales
Description La déclaration de variables locales à un bloc d'instructions est
déconseillée.
Rôle Rendre la maintenance plus aisée en évitant d'avoir des déclarations
n'importe où.
cod_30_recur : Récursivité non recommandée
Description Il n'est pas recommandé d'utiliser la récursivité.
Rôle Rendre le code plus maintenable.
Le premier slogan semble venir de l'envie de faciliter l'exploration des programmes en faisant en sorte que les déclarations soient toutes en des endroits faciles à reconnaître (par exemple, en C, les débuts de procédures). C'est ignorer que beaucoup d'outils facilitent l'exploration des programmes (par exemple, les éditeurs syntaxiques de l'environnement Centaur [Borras et al. 89]), et que par ailleurs, rendre des déclarations locales permet de les gérer plus précisément en rapprochant le texte des déclarations des bribes de programme qui les utilisent.
Le second slogan nous paraît être un archaïsme absurde et ne reposer que sur le refus d'admettre que la maîtrise du déroulement précis des programmes peut échapper au programmeur. Si le besoin est réellement d'empêcher la création dynamique et non-bornée d'objets et donc la saturation, ce n'est pas la récursivité qu'il faut interdire, mais la récursivité non-primitive et aussi la boucle while. En effet, même si cette dernière ne consomme pas nécessairement de mémoire, elle peut consommer des entiers, et alors la saturation se traduit par un débordement. Il est évident que peu de langages rendent cette nuance visible. Un langage répondant vraiment aux impératifs qui sont à l'origine de ce slogan devrait présenter la récursivité primitive (ou mieux l´induction structurelle* sur les termes d'un type donné) comme une structure de contrôle de base.