Le but du code est-il «idiomatique» pour réduire les frais généraux cognitifs?

J'essaie d'expliquer à quelqu'un que la façon dont il a écrit le code est difficile à comprendre, et si vous le refactorisez, il est plus facile à lire. Ce style de code que je veux utiliser est communément appelé code «idiomatique».

Mais l'expression code idiomatique apporte un bagage d' exactitude morale , qui n'est pas un grand facteur de motivation pour amener les gens à changer leur style de codage. Une façon plus positive de dire cela est un code qui suit le style commun - mais pour un penseur critique qui apparaît comme un raisonnement de mentalité de troupeau.

La façon dont j'ai trouvé l'explication de cette idée d'une manière qui motive les gens à changer leur code est la suivante:

• écrire le code de manière à réduire les frais cognitifs du lecteur (par exemple, je ne me souviens pas s'il s'agit du premier type de vecteur - ou du 5e type de vecteur)
• code qui facilite la compréhension de l'intention (par exemple, à quoi sert ce vecteur?)

(Soit dit en passant, je sais que le livre The Joy of Clojure, avant sa première publication, avait le projet de titre Idiomatic Clojure. Il semblerait donc qu'il y ait une raison pour rendre le code «idiomatique», pour «apporter de la joie» au lecteur ).

Ma question est: le but derrière le code est-il «idiomatique» pour réduire les frais généraux cognitifs?

Premièrement, je ne suis pas sûr qu'il y ait une sorte de «correction morale» dans le terme «idiomatique». La définition simple du dictionnaire est simplement

propre ou caractéristique d'une langue ou d'un dialecte particulier: le français idiomatique.

Oui, le code idiomatique réduit généralement les frais généraux cognitifs, en particulier au niveau des définitions d'interface où les bibliothèques standard et toutes les bibliothèques tierces dont le projet a besoin sont (virtuellement) toutes idiomatiques.

Comme argument de vente, cependant, je me concentrerais sur ce que la réduction des frais généraux cognitifs fait pour vous. Cela permet aux programmeurs de repérer plus facilement les erreurs car ils n'essaient pas de démêler le code écrit dans un style unique pour comprendre où il est subtilement désactivé par un ou mal gérer un cas de bord. Cela facilite la révision du code d'autres personnes, ce qui rend plus probable que l'équipe fasse de véritables révisions qui identifient les vrais problèmes plutôt que de discuter de la syntaxe.

Au-delà de la réduction des frais généraux cognitifs, le code idiomatique est généralement un code plus efficace. La plupart des idiomes dans une langue particulière évoluent parce que la langue est conçue pour aborder les problèmes d'une manière particulière. Les compilateurs ou interprètes que vous utilisez concentreront leurs optimisations sur le code idiomatique. Si vous utilisez un langage où la récursivité est le moyen idiomatique de structurer un morceau de code, par exemple, vous pouvez être presque certain que votre compilateur implémente la récursivité de queue. Si vous utilisez un langage où la récursivité n'est pas idiomatique, cela est beaucoup moins probable. Il est peu probable que la récursivité de la queue ne puisse pas être implémentée partout, mais la plupart des rédacteurs de compilateurs ne se concentreront pas sur des choses qui ne se produisent pas couramment.

Je ne sais pas d'où vous vient l'idée que les idiomes ont une connotation morale. Les idiomes ne sont qu'un moyen d'exprimer des choses. Ce sont des modèles à une échelle plus grande que des mots ou des phrases individuels.

Si je vous disais qu'il faut hurler avec les loups, vous ne sauriez pas ce que je voulais dire, même si c'est un idiome allemand bien connu. Si, OTOH, je vous ai dit, quand à Rome, faites comme les Romains, vous sauriez immédiatement de quoi je parle, parce que j'ai utilisé le bon idiome anglais.

Les langages informatiques ne sont pas différents.

En fait, un autre nom pour "idiome" dans le monde de la programmation est "modèle d'implémentation". Cela relie l'idée à l'idée de modèles, qui vient de l'architecte (brique et mortier et non bits et octets) Christopher Alexander. La plupart des programmeurs connaissent les modèles de conception, certains connaissent les modèles d'architecture, qui sont des modèles à une échelle plus grande que les modèles de conception. Les idiomes sont des modèles à une échelle plus petite que les modèles de conception.

La plupart des langues se prêtent intentionnellement à un style particulier. Le code écrit dans ce style est ce qui est idiomatique. Si vous regardez au-delà du fait circonstancié que votre choix d'environnement d'exécution restreint votre choix de langues disponibles, vous devez choisir des langues car le problème à résoudre est facile à exprimer dans les idiomes particuliers d'une langue.

La plupart des gens ne comprennent pas cela. Par exemple, de nombreux programmeurs Java s'efforcent de conserver le même style lorsqu'ils doivent écrire JavaScript (ils auraient pu écrire Java et le compiler de façon croisée, pensez-vous) et réussir dans une certaine mesure - écrire du code idiomatique Java en JavaScript - mais ils auront toujours l'impression de combattre JavaScript. Manquer certaines fonctionnalités ou avoir du mal à les émuler.

Le code idiomatique est bon. C'est difficile pour les étrangers, mais ils peuvent apprendre. En fin de compte, le code doit être maintenu pendant des années, donc si vous pouvez trouver un langage dans les idiomes dont le programme sous-jacent peut être exprimé de manière simple, c'est ce que vous devez faire.

Permettez-moi de préciser qu'il existe certainement une telle chose comme la surutilisation des idiomes (ou les caractéristiques du langage sous-jacent). Si vous utilisez des modèles C ++ pour exécuter des parties importantes de la logique d'application au moment de la compilation, ou si votre programme Lisp complet est un appel à une macro qui se déroule dans la réalité de manière pratiquement imprévisible, si votre solution Java d'un problème simple se gonfle vers les proportions de FizzBuzzEnterpriseEdition ... vous vous trompez.

Les gens disent que le code doit être facile à lire. Ce n'est que la moitié de la vérité. Il doit être facile à comprendre, ce qui nécessite qu'il soit également facile à raisonner. Cela nécessite une utilisation adéquate des abstractions. Comme pour la plupart des choses, il s'agit de trouver le bon équilibre.