Devez-vous sacrifier la lisibilité du code avec l'efficacité du code? [fermé]

Devez-vous sacrifier la lisibilité du code avec l'efficacité du code?

par exemple 3 lignes de code en 1 ligne.

J'ai lu dans Code Craft de Pete Goodliffe que la lisibilité est essentielle.

Tes pensées?

"Moins de lignes" n'est pas toujours la même chose que "plus efficace". Je suppose que vous voulez dire "Faut-il raccourcir un programme au détriment de sa lisibilité".

Les programmes doivent être écrits pour que les gens puissent les lire et, accessoirement, pour que les machines s’exécutent.

-Abelson & Sussman, Structure et interprétation des programmes informatiques

En général, je pense qu'il est plus important qu'un programme soit facile à comprendre que d'être court. Je devrais cependant noter que raccourcir un programme le rend souvent plus lisible (il est évident que le seuil commence quand le code commence à ressembler à du bruit de ligne, mais jusque-là, exprimer quelque chose de façon plus succincte le rend plus clair).

Il existe des exceptions spécifiques (telles que vos scripts de shell personnels ou l'un des codes de modification de données) que personne n'aura jamais besoin de gérer, et vous seul aurez besoin de lire. Dans cette situation, il est probablement correct de sacrifier une partie de la lisibilité au profit de l’opportunité, pour autant que vous puissiez la comprendre.

Parfois oui.

La lisibilité est une bonne chose à faire. La plupart du code écrit pour des applications métiers typiques sera suffisamment performant et il est important de se concentrer sur la lisibilité. Dans des domaines plus exigeants en termes de performances (tels que la programmation de jeux vidéo ou le calcul intensif), il peut être important de renoncer à la lisibilité au profit d'une fonctionnalité de langage particulière qui est horriblement illisible et incroyablement performant.

Pour un exemple de ce dernier, voir l' article de la racine carrée à inversion rapide sur Wikipedia.

Je pense généralement qu'il est préférable de commencer par lire quelque chose et de se préoccuper des performances après, à condition de prendre des précautions de bon sens, comme de ne pas choisir un algorithme O (n ^ 2) au lieu de O (n). Le fait de sacrifier la lisibilité au seul souci de la brièveté est, à mon sens, erroné.

La seule fois que je sacrifierais la lisibilité serait lorsque le code était considéré comme un goulot d'étranglement au niveau des performances et qu'une réécriture permettait de résoudre ce problème. Dans ce cas, l' intention du code doit être bien documentée afin que, en cas de bogue, il puisse être dépisté plus facilement.

Cela ne veut pas dire que la réécriture doit être illisible, bien sûr.

Je l'ai déjà cité et je le cite encore:

Faites le correct,
faites le clair,
faites le concis,
faites vite.

Dans cet ordre.

Wes Dyer

Devez-vous sacrifier la lisibilité du code avec l'efficacité du code?

En termes de code, il est toujours agréable d’être auto-documenté. Mais parfois, cela ne peut pas arriver. Parfois, vous avez besoin d'optimiser et parfois, ce code n'est pas très lisible en soi.

Voici ce que les commentaires ont été inventés pour . Utilise les. Même l'assemblée a des commentaires. Si vous avez écrit une masse de code et qu'il n'y a pas de commentaire en vue, je suis inquiet. Les commentaires n'affectent pas les performances d'exécution, mais quelques notes sur ce qui se passe sont toujours utiles.

Dans mon esprit, il n’ya aucune excuse pour ne pas avoir quelques remarques fondamentales. if ( x == 0 ) /* check if x is 0 */Est clairement totalement inutile; vous ne devriez pas ajouter de bruit inutile au code, mais quelque chose comme ceci:

; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
    push rdp
    ; ...

Est très utile.

Devez-vous sacrifier la lisibilité du code avec l'efficacité du code?

Si votre objectif actuel est l'efficacité (comme dans la phase d'optimisation) et que vous savez, vous avez des métriques, n'est-ce pas? - cette ligne de code est le goulot d'étranglement actuel, alors oui.

Sinon, non: la lisibilité vous permettra (ou à un autre) de pouvoir modifier ce code ultérieurement pour le rendre plus efficace, car plus facile à comprendre.

Personne ne gagne le code de golf

par exemple 3 lignes de code en 1 ligne

Une idée particulièrement terrible.

Coût pour jouer au golf de code - très élevé.

Coût de maintenance des programmes illisibles - astronomique.

Valeur de ce type de code minimisé - zéro. Cela fonctionne toujours, mais ne fonctionne pas "mieux".

Efficacité judicieusement choisie

Coût pour choisir le bon algorithme et la bonne structure de données - modéré.

Coût pour maintenir le bon algorithme et la bonne structure de données - faible.

Valeur du bon algorithme et de la structure de données - élevée. L'utilisation des ressources est faible.

Foolish ("micro-optimisation") Efficacité

Coût pour jouer autour de la micro-optimisation - élevé.

Coût de maintenance du code micro-optimisé et illisible - très élevé.

Valeur de la micro-optimisation - varie. Lorsqu'il y a une valeur non nulle ici, les coûts l'emportent toujours sur elle.

Cela dépend si nous parlons d'efficacité en termes de rapidité d'exécution du code ou d'efficacité en termes de rapidité avec laquelle le développeur peut écrire le code. Si vous sacrifiez la lisibilité du code pour pouvoir taper le code très rapidement, vous risquez probablement de perdre du temps en termes de débogage.

Cependant, si nous parlons de sacrifier la lisibilité du code en termes de rapidité d'exécution du code, il s'agit probablement d'un compromis acceptable tant que le code doit être préformé de manière efficace. Écrire quelque chose qui va aussi vite que possible simplement parce que vous le pouvez n’est pas une raison aussi valable que parce que c’est quelque chose qui ressemble à la racine carrée rapide rapide où la performance est la clé. L'astuce consiste à équilibrer le code et à s'assurer que, même si le code source est difficile à lire, les commentaires décrivant ce qu'il explique expliquent ce qui se passe.

De nombreuses astuces, censées rendre le code plus rapide, mais ont tendance à le rendre moins lisible, ne sont plus nécessaires, car les compilateurs sont devenus très intelligents (même plus intelligents que la plupart des développeurs) ou les machines sont devenues ridicules rapidement.

Je n'accepte pas l'argument "lisibilité sur performance". Laissez-moi vous donner une réponse avec une autre tournure.

Quelques antécédents: Vous savez ce qui me rend malade? Lorsque je double-clique sur Poste de travail et que je dois attendre qu’il soit rempli. Si cela prend plus de 5 secondes, je suis vraiment frustré. La chose stupide est, et ne blâmez pas simplement Microsoft pour cela, c’est que dans certains cas la raison pour laquelle cela prend tant de temps est qu’il faut décider quelle icône afficher! C'est vrai. Je suis donc assis, je ne suis intéressé que par mon lecteur C: et je dois attendre que le pilote accède à mon CD-ROM pour lire l'icône à partir de là (en supposant qu'il y ait un CD dans le lecteur).

D'ACCORD. Alors, pour une seconde, imaginez toutes les couches entre moi en double-cliquant sur Poste de travail et en train de parler via des pilotes au CD-ROM. Maintenant, imaginez que chaque couche était ... plus rapide ...

Vous voyez, derrière tout cela se trouvent des milliers de programmeurs heureux parce que leur code est "plus lisible". C'est génial. Je suis content pour toi. Mais du point de vue de l'utilisateur, ça craint (terme technique). Et vous dormez donc bien la nuit en vous disant que vous avez agi correctement en veillant à ce que le code soit plus lisible et plus lent. Même légèrement plus lent que ce ne peut être. Et ainsi, des milliers de développeurs le font et nous finissons par attendre nos PC à cause de vous. À mon avis, vous n'êtes pas digne. Je ne dis pas que vos toutes premières lignes doivent être les meilleures.

Voici mon approche: Tout d'abord, faites-le fonctionner, puis accélérez-le. Essayez toujours d’écrire du code efficace et si vous devez sacrifier la lisibilité, complétez-le avec des commentaires. Je ne sacrifierai pas l'efficacité pour qu'un programmateur médiocre puisse la maintenir. Je vais cependant expliquer mon code, mais si cela ne suffit pas, je suis désolé, vous êtes tout simplement incompétent pour travailler ici. Parce qu'ici, nous écrivons du code rapide et lisible, et bien qu'il y ait un équilibre, on peut expliquer le code lisible alors que l'inefficacité est simplement inacceptable.

Cette question m'est souvent venue à l'esprit lorsque les entretiens sont discutés au bureau. En tant que diplômé, il y a de nombreuses années, on m'a posé la question "Pensez-vous que le code est auto-documenté?". Maintenant, je devais répondre à cette question en tant que programmeur et en ce qui concerne l'intervieweur, c'était une question en noir et blanc, il n'y avait donc pas de moyen terme. Le processus doit survivre à l'individu, car les gens vont et viennent plus rapidement et vous voulez que les nouveaux départs soient prêts le plus tôt possible. Plus le code est lisible, plus il est facile de comprendre ce qui se passe.

Il y a quelque temps, j'avais lu un livre plutôt intéressant intitulé Domain Driven Development: Conception axée sur le domaine: aborder la complexité au cœur des logiciels. Certes, la lecture est un peu sèche au début, mais le matériel est bien présenté. Cela montre une bonne approche qui conduit à des systèmes qui se documentent bien. Le langage est le moyen de communication de votre solution. Plus la solution est clairement exprimée, plus il est facile de s’adapter si performace devient un facteur essentiel. C'est ma conviction et cela semble avoir bien fonctionné pour moi.

Il est rare que le retour sur investissement lié à une exécution plus rapide du code, au détriment de sa lisibilité, en vaille la peine. Les ordinateurs modernes fonctionnent si vite que je doute que vous souhaitiez cela. Si un ordinateur exécute le code, ce code doit être conservé.

À cette fin, je trouve la lisibilité très importante. Bien sûr, comme indiqué à de nombreuses reprises, ce n'est pas parce que le code est lisible que c'est plus lent.

Un bon exemple est un nom de variable: $a

C'est quoi $a?? Ceci est hors contexte, donc vous ne pouvez pas répondre à cette question, mais avez-vous déjà rencontré ce problème dans du code réel? Supposons maintenant que quelqu'un a écrit $file_handle- qu'est-ce que c'est maintenant? C'est clair même hors contexte. La longueur du nom de la variable fait une différence insignifiante pour l'ordinateur.

Je pense qu'il y a du bon sens à avoir ici.

Certaines applications peuvent nécessiter un raccourci de décalage que tout le monde ne comprendra pas, mais je pense qu'à un moment donné, les rendements diminuent et que trouver un scénario est rare *.

* Cela dépend de l'industrie et d'autres choses du même genre. Je regarde cela du point de vue du développeur de logiciels d'entreprise (Business Information Systems).

Pour examiner cela sous un autre angle (mais pas pour faire de la réflexion), je travaille dans une entreprise qui fabrique des SAAS. Lorsqu'un site tombe en panne, nous devons le réparer vraiment, très vite - généralement, quelqu'un d'autre corrige le code d'un autre développeur.

Je beaucoup plutôt quelqu'un faire quelque chose de très inefficacement mais lisible que de le faire et de fantaisie « rapide ». Nos serveurs Web sont à la pointe de la technologie et une demande ne doit pas être livrée en un millionième de seconde. Nous n'avons pas de problèmes de charge.

Donc, en pratique, je pense que vous risquez davantage de vous blesser ou de blesser les autres ... (Je préférerais que mon week-end revienne.)

Dans la plupart des cas, la réponse est "Faites confiance à votre compilateur pour faire son travail" et écrivez un code lisible. Cela implique que le code soit structuré logiquement (c'est-à-dire qu'il ne contient pas de spaghetti) et auto-documenté (c'est-à-dire des noms de variables, de fonctions, etc. suffisamment clairs). Code de supplément qui n'est pas auto-documenté avec des commentaires significatifs. Ne commentez pas pour le commentaire, c.-à-d.

x++; // Add one to x

Commentez plutôt pour vous, le lecteur, dans 6 mois ou 12 mois ou quelque temps suffisamment long. Adoptez une norme de codage et suivez-la.

Le code propre est un code rapide. Clairement écrit, le code facile à gérer a tendance à être plus rapide, car il indique que le programmeur a compris la tâche à accomplir et a refactorisé le code pour en faire son objectif principal.

En outre, les compilateurs modernes optimisent très efficacement les instructions. Le nombre de lignes de code que vous tapez pour faire quelque chose et ce que le compilateur crée en termes d'instructions ne sont pas nécessairement liés. Renseignez-vous sur les compilateurs pour comprendre pourquoi c'est le cas.

Lorsque je travaille sur des éléments basés sur les performances, tels que les graphiques, je sacrifie parfois la lisibilité / la maintenabilité lorsque je travaille sur le traitement d'images, lorsque je travaille sur le plus profond des algorithmes imbriqués où de petites optimisations peuvent avoir un effet majeur. Et même dans ce cas, je ne le fais qu'après le profilage pour que les changements accélèrent réellement les choses. Je ne peux pas vous dire combien de fois j'ai essayé des «optimisations» codées à la main, mais je me suis rendu compte que l'application avait été ralentie en raison de la manière dont le compilateur avait optimisé le code manuscrit.

La lisibilité est une excuse pour les programmeurs incompétents et paresseux (il en va de même pour la "simplicité" utilisée comme argument pour défendre un algorithme / design de merde)!

Pour chaque problème, vous devez rechercher la solution optimale! Le fait que les ordinateurs soient rapides n’est pas une excuse pour gaspiller des cycles de processeur. La seule contrainte devrait être "le temps de livrer". Notez que "solution optimale" signifie ici celui que VOUS pouvez proposer (nous ne pouvons pas tous proposer la meilleure solution; nous ne disposons pas non plus des compétences / connaissances nécessaires pour les mettre en œuvre).

Comme quelqu'un d'autre l'a mentionné, s'il y a des aspects "difficiles à comprendre" dans une solution, c'est à cela que servent les commentaires. L'ordre "correct, lisible, rapide" (ou quelque chose du genre), dont quelqu'un d'autre a parlé, n'est qu'une perte de temps.

J'ai vraiment du mal à croire qu'il existe des programmeurs qui, lorsqu'ils sont confrontés à un problème, pensent qu'ils se trouvent dans les lignes "... cela doit être fait comme ça, mais je vais faire de cette façon qui est moins efficace mais plus lisible / maintenable et autres telles merde ... ". L'erreur est que le prochain développeur (en voyant les inefficiences) modifiera probablement le code et que le prochain en fera de même, etc. Le résultat final est qu'après quelques versions, le code deviendra ce que l'original développeur aurait dû écrire à la 1ère place. La seule excuse pour le développeur original est un. il / elle n'y a pas pensé (assez bien) et (comme mentionné précédemment) b. contraintes de temps et de ressources.

si diminuer la lisibilité aide la performance / l'optimisation du code (comme dans swfobject et d'autres bibliothèques Js ), il est bon de continuer à écrire du code bien formaté et lisible clairement et de le convertir en illisible / optimisé dans le cadre du processus de "compilation" / release.