Le codage comme forme d'écriture

May 10 2023

Ce que les développeurs de logiciels peuvent apprendre des auteurs de prose

Il y a un endroit où la rivière Snake dans le Wyoming se courbe vers le nord, s'élargit et ralentit. Les orignaux broutent les nénuphars, les pélicans attrapent des poissons, les loutres jouent.

Il y a un endroit où la rivière Snake dans le Wyoming se courbe vers le nord, s'élargit et ralentit. Les orignaux broutent les nénuphars, les pélicans attrapent des poissons, les loutres jouent. Puis la rivière se recroqueville sur elle-même et reprend son voyage vers l'ouest vers les montagnes.

Vous verrez le même chemin en boucle si vous regardez ma carrière jusqu'à présent. Je suis un développeur de logiciels devenu professeur de sciences humaines qui est redevenu développeur de logiciels. Entre l'ingénierie et les sciences humaines, il y a une distance bien connue, mais je l'ai suffisamment parcourue pour savoir qu'elle est plus courte que les gens ne le pensent. En cours de route, j'ai remarqué que certains des conseils dispensés par les auteurs de prose pouvaient également être utiles aux auteurs de logiciels, presque comme si l'écriture de code était une forme d'écriture.¹

Une fois, j'avais besoin de créer une petite fonction qui ajoute un élément à un tableau, mais supprime l'élément s'il s'y trouve déjà. Comme ça:

toggle([], 1) // should return [1]
toggle([1], 1) // should return []

import _ from "lodash";
const toggle = (arr, item) => _.xor(arr, [item]);

Bientôt, cependant, je me suis souvenu de quelques conseils : « Relisez vos compositions, et chaque fois que vous rencontrez un passage que vous trouvez particulièrement beau, biffez-le. C'est un conseil de Samuel Johnson, essayiste du XVIIIe siècle.³ Le picotement d'intelligence, réalisai-je, était un indice que je devais simplifier ma fonction. Je l'ai changé en :

const toggle = (arr, item) =>
   arr.includes(item) ?
   arr.filter((x) => item !== x) :
   [...arr, item];

À mon avis : non.⁴ Bien que plus complexe à certains égards, la nouvelle fonction était tout de même susceptible d'être plus claire pour le codeur moyen, et donc plus facile à maintenir. Une ligne de code peut être syntaxiquement simple mais peu claire, ou claire mais syntaxiquement complexe. Comme une ligne de prose. Pensez à la phrase, "Pourquoi avez-vous apporté ce livre pour lequel je ne veux pas qu'on me lise?"⁵ Il a une syntaxe alambiquée, mais c'est beaucoup plus intelligible que, disons, la phrase syntaxiquement simple, " Le myrmécobe s'est absquatté. Bien que plus laconique, ma nouvelle fonction était plus facile à lire.

S'il avait connu JavaScript, le roi de la prose laconique lui-même aurait peut-être désapprouvé la version plus concise de toggle. "Hemingway" - le roi en question - "ne vous conduit pas au dictionnaire", a dit un jour F. Scott Fitzgerald avec appréciation.⁶ Si elle avait utilisé xor, ma fonction aurait conduit la plupart des lecteurs à la documentation. Sans cela, la fonction est plus déployée, explicite et, pour cette raison, plus explicite.⁷

Le terme laconique vient des Spartiates de l'Antiquité, qui vivaient dans une région appelée Laconie et ne gaspillaient pas leurs mots. Un ennemi leur écrivit un jour : « Si j'envahis la Laconie, je vous chasserai du pays. Ils ont répondu : "Si".⁸

Un précepte sur l'écriture que j'admire ne vient pas d'un romancier ou d'un journaliste mais d'un concepteur de musée. Une bonne écriture, selon Edwin Schlossberg, « crée un contexte dans lequel les autres peuvent penser ».⁹ Cela les aide à imaginer, réfléchir, réagir. Cela leur donne de l'espace pour le faire, comme une exposition de musée. De la même manière, un bon code fait de la place aux lecteurs, pour ainsi dire. Cela les aide à raisonner.

Il est donc généralement logique pour un auteur de code de suivre des modèles que le lecteur moyen comprend déjà bien. Bien que la plupart des développeurs JavaScript soient familiers avec le ternaire (le point d'interrogation et les deux-points) utilisé ci-dessus, beaucoup sont encore plus à l'aise avec un bloc if-else, comme celui-ci :

const toggle = (arr, item) => {
   if (arr.includes(item)) {
      return arr.filter((x) => item !== x);
   } else {
      return [...arr, item];
   }
}

Les auteurs doivent avoir de l'empathie pour leurs lecteurs, et vous devez également avoir de l'empathie pour les personnes qui maintiendront, débogueront ou adapteront votre code. Puisque vous êtes l'auteur, cependant, il est normal d'avoir du mal à se mettre à la place de vos lecteurs. Essayez deux techniques empruntées aux meilleurs écrivains.

Tout d'abord, Helen Sword suggère que vous "visualisez des personnes spécifiques regardant par-dessus votre épaule pendant que vous écrivez". Après tout, "les écrivains les plus engageants sont presque invariablement ceux qui accordent la plus grande attention aux vraies personnes - spécialistes et non spécialistes, collègues et étrangers - aux oreilles desquelles leurs propres mots résonneront."¹¹ Un conseil avisé pour les codeurs également.

Une deuxième technique : mettez votre code de côté pendant un jour ou deux, si vous le pouvez, puis revenez-y. "Terminez la nouvelle, imprimez-la, puis mettez-la dans un tiroir et écrivez d'autres choses", a dit un jour Neil Gaiman à un écrivain en herbe. « Lorsque vous êtes prêt, prenez-le et lisez-le, comme si vous ne l'aviez jamais lu auparavant. S'il y a des choses dont vous n'êtes pas satisfait en tant que lecteur, allez-y et corrigez-les en tant qu'écrivain : c'est de la révision.

de sorte que lorsque nous y reviendrons après un intervalle, il aura l'air de nouveauté et d'être l'ouvrage d'un autre ; car ainsi nous pouvons nous empêcher de considérer nos écrits avec toute l'affection que nous prodiguons à un enfant nouveau-né. ¹³

Il n'est pas trop surprenant que les conseils d'écriture puissent être adaptés à des symboles d'un type différent. Les domaines de la connaissance s'infiltrent souvent les uns les autres, ou comme le dit magnifiquement le romancier Charles Johnson :

Une forme d'expression artistique et intellectuelle nourrit et nourrit les autres. Ce que nous appelons créativité et imagination, ces deux grands mystères, peut être pour certains créateurs vécus comme « globaux » dans leur vie, non localisés dans une seule forme d'expression, mais plutôt diffusant ou débordant d'un genre à l'autre, d'un genre artistique ou artistique à l'autre. discipline intellectuelle à une autre, car toutes les humanités (avec les sciences) sont liées, interconnectées. ¹⁴

Expérimenter dans votre propre codage avec les approches recommandées ici peut nécessiter un changement dans votre routine. Un détour, pour que vous puissiez, comme le fleuve, décélérer et devenir plus réfléchi, plus généreux. Alors prenez une page de la rivière. Il ne suit pas une trajectoire linéaire.

L'analogie codage-écriture a ses limites, bien sûr. Par exemple, les contradictions sont pratiquement interdites dans le code source, et c'est dans l'art, en particulier la poésie, qu'elles trouvent leur justice. Il y a un poème de Fernando Pessoa que j'aime lire à voix haute même si je ne connais pas le portugais. Cela commence:

O poeta é um fingidor
Finge tão complètementamente
Que chega a fingir que é dor
A dor que deveras sente.

Un poète est celui qui feint.
Il simule si complètement le vrai
qu'il simule même les douleurs
et les souffrances affreuses qu'il ressent.¹⁵

Pessoa nous invite à mettre momentanément de côté les idées conventionnelles du vrai et du faux. Il énonce sans vergogne une contradiction : les poètes se cachent derrière leurs poèmes, et ce faisant, ils deviennent visibles à travers eux. Abandonnant la logique booléenne, Pessoa invente sa propre logique. « Un poète est celui qui feint » : qu'est-ce que cela veut dire, sinon « J'invente tout ce que je dis, tout est faux, y compris ces mots-là » ? C'est une déclaration auto-réfutante, un mensonge logique. Mais si vous regardez à travers les mots jusqu'à leurs racines étymologiques, "O poeta é um fingidor" signifie "Un fabricant est un fabricant". Une vérité logique. Comme la douleur simulée dont il parle, l'affirmation du poète est fausse en surface, vraie en dessous. Le code et la poésie offrent des stratégies complémentaires pour faire face à un monde souvent illogique : l'un fournit un refuge contre les contradictions,

Notes de bas de page

[1] : L'analogie codage-écriture a déjà été faite, bien que différemment, par Brian Kernighan et PJ Plauger , Donald Knuth , Richard Gabriel , James Devlin , Jeff Atwood et Rebecca Sutton Koeser , entre autres. Steve McConnell critique l'analogie.

[2] : Voici un exemple de la fonction lodashde la bibliothèque xoren action. Dans Boggle, vous recherchez des mots dans une grille de lettres. Si vous trouvez un mot que personne d'autre n'a trouvé, vous marquez des points pour celui-ci. Supposons que vous créiez une version du jeu en JavaScript. Vous avez ces données :

const wordsFoundByPlayerOne = ["apple", "peel"];
const wordsFoundByPlayerTwo = ["apple", "leap"];
const wordsFoundByPlayerThree = ["apple", "able"];

_.xor(
   wordsFoundByPlayerOne,
   wordsFoundByPlayerTwo,
   wordsFoundByPlayerThree
); // Output: ["peel", "leap", "able"]

[4] : Nous pouvons également créer une alternative très lisible à l'aide deSet :

const toggle = (arr, item) => {
  const set = new Set(arr);
  if (set.has(item)) set.delete(item);
  else set.add(item);
  return Array.from(set);
}

[6] : Cité par le coach d'écriture Gary Gilson dans un article de 2019 .

[7] : En revanche, le blogueur Jeff Atwood a fait la promotion de la « programmation spartiate ».

[8] : Plutarque, Du bavardage .

[9] : Cité par le physicien Konstantin Likharev dans un livre de 2021 .

[10] : Dans son discours de 2012 « La simplicité compte », Rich Hickey soutient que les programmeurs ne devraient pas craindre la difficulté , en partie parce que cela rend notre travail intéressant. Mais notre travail sera plus intéressant s'il se situe dans la zone Boucle d'or entre ennuyeux et éprouvant, comme c'est le cas avec les cours à l'école .

[11] : Helen Sword, Stylish Academic Writing (2012), p. 44. Pour améliorer leur clarté, de nombreux écrivains lisent leur travail à haute voix, en s'écoutant. Le philosophe Jonathan Bennett écrit : « Gilbert Ryle m'a dit un jour : 'Ce qui ne se lit pas bien à l'oreille ne se lit pas bien dans les yeux', et cela a changé ma vie. Plus que toute autre chose, cette idée m'a montré comment commencer à grimper hors de la fosse à ordures jusqu'à la plaine de la prose décente. Kernighan et Plauger offrent un aperçu similaire sur la programmation : « Un moyen utile de décider si un morceau de code est clair ou non est le « test téléphonique ». Si quelqu'un peut comprendre votre code lorsqu'il est lu à voix haute au téléphone, il est suffisamment clair. Si ce n'est pas le cas, il doit être réécrit » ( Éléments du style de programmation , p. 21).