« Lois » et principes de la programmation

Certains grands principes ont fait école en programmation, et certains phénomènes se maintiennent avec une telle régularité qu'on dit d'eux qu'ils sont des « lois » (même si ces « lois » n'ont que rarement la force de ce que l'on qualifierait ainsi dans un domaine comme la physique, par exemple).

Vous trouverez sur cette page des explications sommaires de quelques-unes des principales « lois » et de quelques-uns des principaux principes du monde de la programmation.

« Lois » Principes

Levier de Kernighan

Boy Scout Rule

Loi d'Atwood

DRY (Don't Repeat Yourself)

Loi de Déméter (Principe de moinde savoir)

KISS (Keep It Simple, Stupid!)

Loi d'Eagleson

Principe de Le Châtelier

Loi de Moore

Principe de localité

Loi de Murphy

Principe de moindre surprise

Loi de Walder

Principe ouvert/fermé (Open/Closed Principle)

Loi de Stallman

Principe de paresse

Loi de Zawinski

Principe de Pareto (loi du 80-20)

Nombre de Norris

Principe de Postel

Théorème fondamental de l'informatique

Principe de responsabilité unique

 

La règle de Stroustrup (Stroustrup's Rule)

 

Théorème du plein emploi

 

YAGNI (You Ain't Gonna Need It)

 

YEINU (Your Experience Is Not Universal)

Quelques « lois » de la programmation

Il existe quelques « lois » de la programmation, qui ne sont pas vraiment des lois mais qui, il se trouve, tendent à être vérifiées de manière récurrente. Quelques-unes sont survolées ci-dessous, mais il en existe d'autres bien entendu.

Levier de Kernighan

« Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? »

Pas tant une « loi » qu'un aphorisme, formulé à l'origine dans The Elements of Programming Style, 2e édition, chap. 2, ce que Linus Akesson a nommé, dans http://www.linusakesson.net/programming/kernighans-lever/index.php?print=yes, le Levier de Kernighan nous invite à privilégier la clarté et la simplicité dans notre démarche de programmation, tout comme il nous invite à raffiner notre approche alors que se raffinent aussi notre compréhension et nos aptitudes techniques.

Loi d'Atwood

« Any software that can be written in JavaScript will eventually be written in JavaScript. »

Attribuée à Jeff Atwood (qui l'aurait énoncée dans cet article de 2007 : https://blog.codinghorror.com/the-principle-of-least-power/). Plus d'une décennie après avoir été énoncée, cette « loi » semblait encore s'appliquer telle quelle.

Loi de Déméter (ou Principe de moindre savoir)

« Only talk to your friends . »

Cette « loi » met en valeur l'idée selon laquelle le logiciel bénéficie d'un couplage minimal entre ses composants, du fait que moins un composant possède d'interrelations avec d'autres et moins il sera affecté par les modifications aux interfaces des autres. Cela ne signifie pas qu'il faut concevoir du logiciel monolithique, mais bien qu'il est souhaitable de définir clairement les points de contact et les interfaces entre les modules et de ne conserver que ceux qui sont nécessaires.

La publication originale de cette loi remonterait à 1989 dans un texte de Karl. J. Lieberherr et I. Holland, I. nommé Assuring good style for object-oriented programs (IEEE Software, septembre 1989, pp 38-48).

Loi d'Eagleson

« Any code of your own that you haven't looked at for six or more months might as well have been written by someone else. »

Constat que plusieurs programmeuses et plusieurs programmeurs auront fait. Certains disent que l'auteur est un optimiste, car trois semaines environ suffisent... Il n'est pas clair qui est l'auteur de cette « loi » (voir http://ask.metafilter.com/200910/Who-is-Eagleson-and-where-did-Eaglesons-law-originate/a> pour une brève discussion à ce sujet).

Loi de Moore

« The complexity for minimum component costs has increased at a rate of roughly a factor of two per year... Certainly over the short term this rate can be expected to continue, if not to increase. Over the longer term, the rate of increase is a bit more uncertain, although there is no reason to believe it will not remain nearly constant for at least 10 years. That means by 1975, the number of components per integrated circuit for minimum cost will be 65,000. I believe that such a large circuit can be built on a single wafer. »

Cette « loi », énoncée en 1975 et révisée par son auteur Gordon Moore depuis, nous dit que la densité des microprocesseurs doublera chaque année (en fait, chaque deux ans dans la version révisée). Le texte original peut être lu sur http://download.intel.com/museum/Moores_Law/Articles-Press_Releases/Gordon_Moore_1965_Article.pdf

Concrètement, cette loi a frappé un mur, une limite physique, au début des années 2000. Un texte bien connu et décrivant cette réalité est The Free Lunch is Over, par Herb Sutter.

À ce sujet :

Loi de Murphy

« Tout ce qui peut aller mal ira mal. »

La seule loi qui est plus forte que la loi de la gravité, diront certains. Son origine n'est pas si évidente que cela, mais cette loi gouverne, disons-le ainsi, une forme de « pessimisme amusé » chez ces étranges créatures que nous sommes, nous qui passons une partie de notre vie à faire du débogage.

Loi de Stallman

« Tant que les grandes entreprises domineront la société et écriront les lois, chaque avancée ou chaque changement de la technologie sera pour elles une bonne occasion d'imposer des restrictions ou des nuisances supplémentaires à ses utilisateurs »

Cette « loi » a été formulée par Richard Stallman, l'individu à la tête (morale) du projet GNU et de la Free Software Foundation. J'ai utilisé la traduction proposée par http://www.gnu.org (le texte original est « While corporations dominate society and write the laws, each advance or change in technology is an opening for them to further restrict or mistreat its users »).

Loi de Walder

«  In any language design, the total time spent discussing a feature in this list is proportional to two raised to the power of its position. 0. Semantics 1. Syntax 2. Lexical syntax 3. Lexical syntax of comments »

Ce que nous dit cette loi, en termes généraux, est que dans le design d'un langage, les thématiques qui peuvent sembler essentielles d'un point de vue fondamental tendent à occuper beaucoup moins le plancher lors de discussions que ne le font les thématiques qui touchent directement le quotidien des programmeuses et des programmeurs.

Loi de Zawinski

« Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can »

Ce que nous dit cette « loi » est qu'il existe une pression sur les systèmes informatiques qui les mène inexorablement à se complexifier; que les systèmes viennent éventuellement à être en mesure de prendre en charge la consommation de courriels est un épiphénomène (amusant) de cette complexificiation.

À ce sujet : http://www.catb.org/jargon/html/Z/Zawinskis-Law.html

Comme le rapporte John D. Cook en 2015, le langage Wolfram est l'un des exemples de l'applicabilité de cette « loi » : http://www.johndcook.com/blog/2015/07/17/wolfram-obeys-zawinksis-law/

Nombre de Norris

«  ...the average amount of code an untrained programmer can write before he or she hits a wall »

La citation à gauche est de John D. Cook. Bien que ce ne soit qu'un extrait d'un blogue (fort intéressant, par ailleurs) et qu'on ne parle pas ici d'une loi connue, j'ai choisi d'inclure ce concept dans la liste des « lois » car je le trouve pertinent et savoureux.

Théorème fondamental de l'informatique

«  Any problem in Computer Science can be solved by adding a layer of indirection »

Attribué à Butler W. Lampson, qui l'attribue pour sa part à David Wheeler. Il semblerait que Wheeler aurait complété par « ...outre le problème d'avoir trop de niveaux d'indirection ». Le nom de ce « théorème » originerait d'une remarque d'Andrew Koenig.

Quelques principes importants

Au fil des ans et du développement des pratiques de programmation, quelques grands principes ont fait école et sont reconnus comme des guides généraux, à la fois de la bonne programmation et de la saine gestion de carrière.

Boy Scout Rule

« Instead of just fixing bad code, improve it »

... ou plus simplement :

« Leave things a little cleaner than you found them »

On attribue cette recommandation à Robert C. Martin. Évidemment, en abuser peut nuire au bon fonctionnement d'une équipe de travail – utilisez votre sens du discernement!

Voir aussi :

DRY (Don't Repeat Yourself)

« Every piece of knowledge must have a single, unambiguous, authoritative representation within a system »

Énoncé à ma connaissance par Dave Thomas et Andrew Hunt dans The Pragmatic Programmer, ce principe est souvent décrit comme la règle de trois :

Quelques textes à ce sujet :

KISS (Keep it Simple, Stupid!)

Un dénommé Johnson aurait été le premier à énoncer ce principe. Le logiciel est un objet éminemment et intrinsèquement complexe. Ce que KISS nous intime de faire est de chercher la solution simple, la démarche simple, de penser à l'usager – de viser la convivialité.

Plusieurs idées connexes existent, mais l'une des maximes les plus connues parmi celles se rapprochant du principe KISS est celle de Saint-Exupéry (que je paraphrase ici), à l'effet que la perfection survient non pas lorsqu'on a ajouté tout ce qu'il y avait à ajouter, mais bien lorsqu'on a enlevé tout ce qu'il y a de superflu.

Selon Sander Rossel en 2015, KISS serait le principe d'entre les principes : http://simpleprogrammer.com/2015/08/19/kiss-one-best-practice-to-rule-them-all/

Principe de Le Châtelier

Le principe de Le Châtelier, applicables aux systèmes complexes en chimie, mais paraphrasé en informatique sous cette forme :

« Every complex system resists its proper functioning »

La forme originale du principe est « When a system at equilibrium is subjected to change in concentration, temperature, volume, or pressure, then the system readjusts itself to (partially) counteract the effect of the applied change and a new equilibrium is established », mais c'est plus amusant quand on le prend d'une perspective architecturale en informatique. J'ai pris la forme paraphrasée donnée à gauche de ce bref texte de Raymond Chen (qui l'a lui-même prise dans un livre nommé Systemantics, que je n'ai malheureusement pas la) en 2008 : http://blogs.msdn.com/b/oldnewthing/archive/2008/04/16/8398400.aspx. Dans ce texte, Raymond Chen réfère aussi à ce qu'ils nomme le théorème fondamental de la tolérance aux pannes (traduction libre), soit que « Every complex system is operating in an error mode ».

Principe de localité

Les programmes tendent à réutiliser les instructions et les données à promixité de celles les plus récemment utilisées.

Ce principe rejoint le principe de Pareto, du moins dans son acception la plus commune.

J'ai, personnellement, une interprétation personnelle de ce principe : règle générale, plus une définition est locale, mieux ce sera pour vos programmes et pour vous. Visez variables locales, petites fonctions, objets cohérents, etc.

 À moins d'avoir une excellente raison de ne pas le faire, préférez les structures de données favorisant la proximité (tableaux, vecteurs). Ceci facilitera la tâche des moteurs d'optimisation de vos compilateurs, tout en améliorant les accès aux antémémoires de votre ordinateur et en facilitant l'entretien de vos programmes. Pensez petit, pensez local.

Principe de moindre surprise

« People are part of the system. The design should match the user's experience, expectations, and mental models »

Je peine à trouver l'énonciateur initial de ce principe, mais Eric S. Raymond en parle dans http://www.faqs.org/docs/artu/ch11s01.html et y fait référence à Jef Raskin, The Humane Interface.

Le principe ouvert/ fermé (Open/ Closed Principle)

« Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification »

Ce principe est l'une des idées clés de la programmation orientée objet. Le texte original est de Bertrand Meyer.

Voir aussi :

Principe de paresse

Je n'ai pas de citation particulière ici outre la plus évidente, énoncée par plusieurs : « Good programmers are lazy »

Quelques références à des gens affirmant ce principe vous apparaîtront sans peine avec la plus humble recherche dans Internet...

Énoncé par de nombreux individus, ce principe nous rappelle qu'un bon programmeur écrit typiquement moins de lignes de code et déploie moins d'efforts apparents pour un meilleur impact. Il est, règle générale, un peu absurde de mesurer la qualité du travail d'une programmeuse ou d'un programmeur sur la base de la quantité de lignes de code que cet individu produit dans un intervalle de temps donné. Cependant, notez qu'avoir l'air paresseux peut être extrêmement ardu, et qu'une ligne de code en apparence simple est souvent terriblement plus difficile à écrire que ne le serait son équivalent en plusieurs dizaines (ou plusieurs centaines, ou plus encore) d'instructions.

Le principe de Pareto (loi du 80-20)

« For many events, roughly 80% of the effects come from 20% of the causes »

Énoncé dans le contexte de l'administration par un dénommé Vilfredo Pareto, ce principe s'applique à plusieurs autres domaines, et est fameusement applicable à l'informatique.

Ce principe a été repris par plusieurs individus importants, dont Donald E. Knuth qui nous a indiqué l'importance d'optimiser nos programmes au bon endroit, du fait que moins de 20 % du code consommera plus de 80 % du temps d'exécution.

Ce que nous explique ce principe, en fait, est l'importance de cibler nos interventions. On peut optimiser des semaines durant une fonction pour n'obtenir qu'un retour microbien sur l'investissement si l'on n'a pas pris la peine au préalable de s'assurer que cette fonction était un réel goulot d'étranglement dans notre programme. Vive les profileurs!

En 2012, John D. Cook a écrit ce commentaire à propos du logiciel écrit sur la base du principe 80-20 :

Le principe de Postel

« Be conservative in what you do, be liberal in what you accept from others »

Ce principe, attribué à John Postel, est l'un des principes fondateurs de l'approche qui sous-tend le protocole TCP, et se veut une proposition pour augmenter la résilience et la robustesse du code :

Une critique vive de ce principe, formulée en 2013 : http://programmingisterrible.com/post/42215715657/postels-principle-is-a-bad-idea

Le principe de responsabilité unique (Single Responsibility Principle)

« Every class should have a single responsibility. That responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility »

Là où l'encapsulation est un principe OO selon lequel un objet est responsable de son intégrité, du respect de ses invariants, le principe de responsabilité unique nous indique qu'une classe ne devrait être responsable que d'une seule chose, typiquement d'une seule ressource.

Sur le plan des maximes, je dis souvent « une classe, une vocation », donc qu'il devrait être possible de dire par une phrase courte ce à quoi sert chaque classe.

Sur le plan technique, une classe destinée à prendre en charge une ressource ne devrait justement prendre explictement en charge qu'une seule ressource; si une classe doit gérer deux ressources (disons un pointeur et un fichier), alors mieux vaut s'assurer que ces deux ressources sont, individuellement, prises en charge chacune par un objet distinct, pour que la classe « responsable » de deux ressources ne soit en fait responsable d'aucune, déléguant cette responsabilité (sans doute par composition) à deux entités distinctes, chacune respectant le principe de responsabilité unique.

La « règle de zéro », énoncée par Martinho Fernandes, rejoint philosophiquement ce principe.

Texte de 2014 sur le sujet, par Robert C. Martin, à qui l'on attribue la paternité de ce principe : http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

Règle de Stroustrup (Stroustrup's Rule)

« For new features, people insist on LOUD explicit syntax.

For established features, people want terse notation »

Attribuée à Bjarne Stroustrup qui l'aurait entre autres énoncée lors d'une conférence en 2014, et qui met de l'avant que ce qui compte dans un design évolue à travers le temps.

Texte de Dave Herman en 2017 à propos de cette règle et de son impact dans le design du langage Rust : https://thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/

Théorème du plein emploi

« No algorithm can optimally perform a particular task done by some class of professionals »

Ce « théorème » qui n'en est absolument pas un est venu à mon attention en 2015. Il se trouve que les informaticiennes et les informaticiens tendent à travailler à leur propre désuétude, créant et raffinant des systèmes automatisés capables d'accomplir des tâches extrêmement complexes, mais malgré tout, il y a toujours plus à faire le lendemain que la veille. C'est ce que vise à exprimer (maladroitement, sans doute) ce principe.

Voir aussi :

YAGNI (You Ain't Gonna Need It)

« Always implement things when you actually need them, never when you just foresee that you need them »

Énoncé à ma connaissance par Dave Thomas et Andrew Hunt dans The Pragmatic Programmer, ce principe est connexe au principe de Pareto, et nous recommande de n'implémenter une fonctionnalité que lorsqu'elle est nécessaire, pas avant.

On pourrait paraphraser en disant que personne n'a de temps à perdre. Rien n'est plus déprimant que du code destiné à dormir sur une tablette. Si vous envisagez implémenter une fonctionnalité qui sera peut-être un jour utile, il est probable que vous priorités doivent être réorientées vers quelque chose de plus pressant.

YEINU (Your Experience Is Not Universal)

« [...] the person making the statement hasn't realized that [he/she made] an assumption–that other people's experiences are the same »

Ce principe est particulièrement connu des gens qui proposent du logiciel à grande échelle, par exemple des fureteurs pour naviguer sur le Web, et qui accueillent des plaintes basées sur des exprériences locales et difficilement transférables. J'ai découvert le principe sous la forme présentée ici dans le blogue de Nicholas Nethercote, en 2014, qui le présente comme une variante de YMMV (Your Mileage May Vary) : https://blog.mozilla.org/nnethercote/2014/01/02/yeinu-your-experience-is-not-universal/

Lectures complémentaires

Quelques liens pour enrichir le propos.

Quelques lois et principes importants du point de vue de la science telle que prise dans une acception plus large, plus générale :


Valid XHTML 1.0 Transitional

CSS Valide !