3 points par GN⁺ 2023-09-17 | 1 commentaires | Partager sur WhatsApp
  • Un article qui discute de la lisibilité du code linéaire en remettant en cause le point de vue présenté sur le blog Google Testing
  • L’auteur n’est pas d’accord avec l’affirmation du blog Google Testing selon laquelle les fonctions qui séparent les niveaux d’abstraction sont plus lisibles
  • L’auteur soutient qu’un code linéaire, qui se lit de haut en bas, est plus intuitif et plus facile à comprendre qu’un code qui navigue entre différents niveaux d’abstraction
  • L’auteur illustre son propos avec l’exemple d’une fonction qui fait cuire une pizza et s’interroge sur le fait de savoir si cette fonction doit chauffer le four ou si le four doit être préchauffé au préalable
  • L’auteur suggère que la lisibilité du code ne vient pas d’une structure qui sépare les niveaux d’abstraction, mais du fait que chaque partie du code explique clairement ce qu’elle fait
  • L’auteur s’oppose à l’extraction de petites fonctions dans un code linéaire et conclut que, surtout lorsqu’elles ne sont utilisées qu’une seule fois, leurs avantages ne compensent pas la perte de linéarité
  • L’auteur souligne aussi un problème potentiel lié à la fonction de cuisson de la pizza, en se demandant pourquoi un nouveau four serait créé à chaque préparation, ce qui pourrait entraîner des problèmes de performance dans un vrai code
  • L’auteur propose que le four soit un paramètre de la fonction, que sa fourniture relève de la responsabilité de l’appelant, et que la fonction retourne une boîte plutôt qu’une pizza

1 commentaires

 
GN⁺ 2023-09-17
Avis sur Hacker News
  • La lisibilité du code linéaire et du code modulaire relève d’une question de style et demande du bon jugement ainsi que du discernement.
  • Une abstraction excessive peut entraîner un couplage prématuré du code.
  • Extraire des fonctions pour abstraire des unités de travail peut clarifier un algorithme, mais cela doit être utilisé avec prudence.
  • Le code d’exemple fourni est simple et peu extensible. Il faut aussi prendre en compte la réutilisabilité et la possibilité de tests unitaires.
  • Un refactoring excessif peut compliquer davantage la maintenance à cause du besoin de déplacer d’autres parties du code.
  • Le code linéaire est facile à lire parce qu’il suit l’ordre d’exécution, mais il passe mal à l’échelle dans les grandes bases de code.
  • Des fonctions concises avec des piles d’appels profondément imbriquées peuvent devenir un cauchemar dans une grande base de code.
  • Un bon code linéaire est plus lisible, mais plus difficile à maintenir et à tester.
  • C’est une bonne pratique de garder les fonctions aussi petites que possible et proches d’un objectif unique.
  • La structure du code doit être organisée en fonction des cas d’usage métier afin d’être facile à faire évoluer.
  • Le code linéaire comme le code modulaire se lisent de façon linéaire, mais l’ordre des fonctions peut influencer la lisibilité.
  • Le vrai code est souvent plus complexe, et un aperçu de haut niveau est nécessaire pour éviter que le lecteur ne se perde dans les détails.