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 |
|---|---|
|
Loi de Déméter (Principe de moindre savoir) |
|
|
You Could Not Do Better By Hand |
|
|
You Don't Pay For What you Don't Use |
|
|
Zero Overhead Principle |
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.
« 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.
« 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.
« 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).
« 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 pour une brève discussion à ce sujet).
« If any single optimisation makes a routine run two or more times faster, then you’ve broken the code »
Cette loi est plus un constat empirique de Matt Godbolt à l'effet que si une optimisation donne des résultats presque incroyables, il y a probablement anguille sous roche...
« With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody »
Constat pragmatique formulé par Hyrum Wright, auquel d'autres (par exemple Titus Winters et Shane Kirk – dans son cas, voir http://shanekirk.com/2016/12/hyrums-law/) adhèrent, et qui guide plusieurs autres pratiques de développement logiciel.
« 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 :
« 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.
« When writing code, it's often the case that you end up computing a value that the calling function doesn't currently need. Later, however, this value may be important when the code is called in a different situation. In this situation, you should obey the law of useful return: A procedure should return all the potentially useful information it computed. »
Cette « loi » énoncée par Alexander Stepanov d dans From Mathematics to Generic Programming indique qu'une fonction qui a calculé une information susceptible d'être utile devrait chercher à rendre ce résultat disponible, pour éviter d'imposer à l'appelant de la recalculer ultérieurement.
Un exemple concret de ce principe est la modification, avec C++ 17, du type de retour de la méthode emplace_back() d'un std::vector<T> en C++. Originalement void, suivant la forme de la fonction push_back() qui existait déjà, son type de retour a été modifié, de manière fort avantageuse d'ailleurs.
En effet, push_back() accepte un objet déjà construit et l'insère à la fin d'un vecteur, alors que emplace_back() accepte les paramètres requis pour créer un objet, puis construit cet objet à la fin d'un vecteur. Retourner une référence sur cet objet qui n'existait pas a priori permet de l'utiliser directement dans l'expression qui a mené à sa création, une économie d'écriture appréciable.
| Avec push_back() | Avec emplace_back() avant C++ 17 | Avec emplace_back() depuis C++ 17 |
|---|---|---|
|
|
|
« All non-trivial abstractions, to some degree, are leaky »
Peu importe la qualité de l'abstraction que nous construirons, nous en frapperons éventuellement les contours, les limites, et nous devrons faire face à cette simple mais essentielle réalité : nous ne pouvons pas faire l'économie de cet acte profond qu'est penser, réfléchir, faire l'effort d'esayer de comprendre ce que nous faisons.
« 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 »).
« 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.
Sous sa forme la plus connue :
« Software is getting slower more rapidly than hardware becomes faster »
La citation d'origine :
« The hope is that the progress in hardware will cure all software ills. However, a critical observer may observe that software manages to outgrow hardware in size and sluggishness »
Cette loi tient d'un constat de Niklaus Wirth, repris par plusieurs individus sous d'autres formes, à l'effet que pour diverses raisons, le rythme auquel les programmes (de même que les programmeuses et les programmeurs) consomment les ressources mises à leur disposition dépasse le rythme auquel ces ressources s'accroissent. Un appel à la discipline?
« What the hardware giveth the software taketh away... » – Joe Armstrong (source)
À ce sujet :
« 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/
« ...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.
« 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.
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.
« 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 :
« Do as the ints do »
Attribué à Scott Meyers, cette maxime nous invite à rédiger nos classes de manière à ce qu'elles soient aussi simples à utiliser qu'un int, la présomption étant qu'un int est le type d'entité le plus simple et le plus naturel à manipuler : si construit normalement, se copie aisément et rapidement, se détruit sans peine et sans conséquences néfastes, etc.
En pratique, c'est une invitation à offrir au code client des entités se manipulant sans problème et dont les opérations sont clairement définies. Remplacer un pointeur par un pointeur intelligent est une application de ce principe, comme l'est aussi le recours à l'idiome pImpl en lieu et place de l'exposition directe d'interfaces.
« 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 :
« There is a coding acronym, DRY, which means Don't Repeat Yourself. The opposite is WET, which means Write Everything Twice.
Today's code reviews are not panning out well... » – Guy Davidson (source)
Quelques textes à ce sujet :
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/
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 ici 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 ». Du même auteur, voir aussi ce texte de 2018 : https://blogs.msdn.microsoft.com/oldnewthing/20180911-00/?p=99695
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. L'idée (informelle) est que moins une variable vit longtemps et mieux c'est.
À 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.
Ce principe entraîne plusieurs conséquences, mais en résumé : quand on a le choix, on vise la plus petite portée possible. C'est meilleur pour la Cache (la pile d'exécution est une zone « chaude » pour la Cache), ça réduit les risques de pollution involontaire du code (ce qui facilite raisonnement sur le code source et, le cas échéant, le débogage), ça réduit la complexité du code à écrire (les variables commencent et finissent de vivre dans une même page sur l'écran), ça réduit les besoins de synchronisation en situation de multiprogrammation, etc.
« 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.
« 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 POO. Le texte original est de Bertrand Meyer.
Voir aussi :
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.
« 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 Pareto appliqué au développement logiciel, texte de 2017 par Phillip Johnston et Rozi Harris : https://embeddedartistry.com/blog/2017/6/14/pareto-principle-for-software
« 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
« 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.
À ce sujet :
« The first five principles are principles of class design. They are:
Attribué à Michael Feathers sur la base d'idées de Robert C. Martin, cet acronyme regroupe les principes sous-jacents à la POO, soit :
https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
Une feuille résumant ce que sous-tend ces principes, proposée par Zuzia Kusznir en 2018 : https://www.monterail.com/blog/solid-principles-cheatsheet-printable
En 2022, Oleksii Trekhleb propose une version illustrée de ces principes : https://itnext.io/solid-principles-sketches-a38865e771f0
Je cite ici Jonathan Wakely, qui lui-même rapporte les mots de Dietmar Kühl, à propos des principes qui guident le choix de standardiser ou non un mécanisme dans la bibliothèque standard de C++ :
« The principle some of us follow is what Dietmar calls "Plauger’s Razor". I hope Dietmar won't mind me quoting his summary of Plauger's guidelines:
There are three reasons for having something in the standard library:
P. J. Plauger est l'un des plus anciens participants au comité de standardisation de C++, et apporte une perspective historique que peu d'autres individus peuvent offrir. En réaction à la citation ci-dessus, il a humblement répliqué :
« R.W. Hamming once confided to me that he was surprised to see a reference in the literature to Hamming's Law. On chasing it down (rather easier in the '60s than now) he discovered it was an offhand remark he had once made that (so often with Hamming) was more profound than he had at the time imagined. I vaguely recall saying something like this a third of a century ago; I still believe it; and I'm flattered that Dietmar remembers it. [...] »
Ce qui suit provient de deux documents distincts (N3248 et N3279), mais des mêmes auteurs. La règle de Lakos est la partie en caractères gras :
« A wide contract for a function or operation does not specify any undefined behavior. Such a contract has no preconditions [...] A narrow contract is a contract which is not wide. Functions or operations having a narrow contract result in undefined behavior when called in a manner that violates the documented contract. [...] Remove noexcept specifications from each library function having a narrow contract, typically (but not always) indicated by the presence of a Requirements: clause. [...] Each library function having a wide contract, that we agree cannot throw, should be marked as unconditionally noexcept. »
Dans N3248 et N3279, tous deux par Alisdair Meredith et John Lakos, une réflexion sur le recours (ou pas) à noexcept dans la bibliothèque standard de C++, John Lakos a mis de l'avant ces principes auxquels, pour l'essentiel, le design de cette bibliothèque a adhéré.
Pour en savoir plus, https://quuxplusone.github.io/blog/2018/04/25/the-lakos-rule/ par Arthur O'Dwyer en 2018 est instructif.
Nicolai Josuttis a formalisé cette règle dans http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0884r0.pdf qui a eu droit à un vote favorable en 2018. Pour voir le texte plus contemporain de cette règle, suivez le lien.
« 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/
« 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 :
« 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.
« [...] 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/
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 :
