Hausse des ifs et baisse des fors

Remonter les conditions dans la fonction

• S’il y a une condition if dans une fonction, il faut envisager de la déplacer vers l’appelant (caller).
• Au lieu que la fonction vérifie elle-même une précondition et ne fasse « rien du tout » si elle n’est pas satisfaite, on fait vérifier la précondition par l’appelant afin que le type garantisse qu’elle est remplie.
• En « remontant » notamment les préconditions, on peut réduire le volume global de vérifications, ce qui constitue l’une des motivations de cette règle.

Descendre les boucles

• Règle issue d’une pensée orientée données, qui introduit la notion de « batch » d’un objet, prend les opérations par lot comme cas de base et traite la version scalaire comme un cas particulier de la version par lot.
• Le principal avantage est l’amélioration des performances, en amortissant les coûts de démarrage et en apportant de la flexibilité dans l’ordre de traitement.
• Par exemple, pour la multiplication de polynômes basée sur la FFT, évaluer un polynôme simultanément en plusieurs points peut être plus rapide que de faire des évaluations individuelles.

L’avis de GN⁺

• Le point le plus important de cet article est la présentation de deux règles de programmation, « remonter les conditions » et « descendre les boucles », afin d’améliorer les performances et la clarté du code dans le développement logiciel.
• Ces règles contribuent à améliorer la lisibilité du code, à optimiser les performances et à réduire le risque de bugs.
• Cet article est intéressant et utile pour de nombreux développeurs, car il apporte des pistes pour gérer la complexité du génie logiciel et écrire du code efficace.

[GN⁺]

Commentaire Hacker News

• Certains trouvent surprenante la réaction négative aux conseils sur la conception orientée données. Comme la plupart des utilisateurs des forums écrivent des applications web, ces conseils peuvent leur sembler dénués de sens. Si, dans votre travail quotidien, vous n’avez pas besoin de penser au cache d’instructions, vous devriez ignorer ces conseils. En regardant le "Typical C++ Bullshit" de Mike Acton, on peut comprendre l’importance de ces conseils.
• Certains estiment que les programmeurs se soucient de rendre le code joli à une « petite échelle », mais pas assez de concevoir correctement l’ensemble de la base de code. Si une fonction est bien nommée, possède une bonne interface, un objectif clair, une documentation appropriée et n’abuse pas des effets de bord, alors il ne faut pas trop se préoccuper du fait qu’elle soit désordonnée ou de la disposition des if et des for.
• Une personne ayant commencé la programmation dans le domaine scientifique estime que les petites optimisations comptent. Utiliser le mauvais ordre de boucles for peut faire passer le temps d’exécution d’une simulation d’une semaine à une heure. Les personnes ayant ce type de parcours optimisent instinctivement l’ordre des for et des if.
• Certains estiment que lorsqu’on a un « conteneur », il faut écrire des fonctions pour la « Thing » métier qu’il contient plutôt que des fonctions sur le conteneur lui-même. Cela rend le code plus flexible et distingue plus clairement le domaine cœur des préoccupations de l’application.
• Faire remonter des if a l’inconvénient de rendre les préconditions et postconditions d’une fonction invisibles directement dans sa définition. Dans les grands projets, ces fonctions peuvent être réutilisées en dehors du contexte prévu, ce qui peut provoquer des bugs. Utiliser un framework de contrats peut être une solution, mais cela oblige à écrire les conditions deux fois, dans les contrats et dans le code.
• Dans un exemple utilisant Rust, le système de types puissant de Rust évite le besoin de programmation défensive requis dans d’autres langages. Il n’est pas souhaitable qu’un programmeur C ne vérifie pas la validité d’un pointeur passé à une fonction et provoque une déréférence de NULL. Certains if doivent être en haut de la fonction et non en bas, et les erreurs doivent bien se propager.
• Certains pensaient que l’article allait déboucher sur un exemple de code précis, mais ce n’était en réalité pas le cas. Un autre exemple est proposé à la place de celui qui était attendu.
• Sans contexte approprié, ces conseils peuvent sembler étranges, voire mauvais. Les boucles for et les instructions if sont toutes deux des opérations de contrôle de flux, donc certaines affirmations de l’article paraissent dépourvues de sens. Les affirmations sur les performances sont les plus solides, mais elles devraient être considérées en dernier parmi les préoccupations liées aux conseils généraux.
• Certains ne sont pas convaincus que ce genre de règle générale puisse s’appliquer à du vrai code. Ces règles sont souvent vues comme un dogme erroné, et de jeunes programmeurs peuvent les interpréter de travers et écrire un code pire. On ne peut pas faire remonter un if quand la condition dépend souvent d’un walrus.
• Faire remonter un if de précondition chez l’appelant est, selon certains, une idée affreuse. Cela peut être pertinent dans des cas particuliers, mais en général on ne le souhaite pas. Dans une bibliothèque, il faut vérifier les préconditions à la frontière externe afin que l’implémentation interne puisse avancer sans hypothèses implicites. Dépendre de la vérification faite par l’appelant annule cet objectif.