Devriez-vous sacrifier la lisibilité du code avec son efficacité?
Devriez-vous sacrifier la lisibilité du code avec son efficacité?
par exemple. 3 lignes de code en 1 ligne.
J'ai lu dans Code Craft par Pete Goodliffe que la lisibilité est la clé.
Tes pensées?
"Moins de lignes" n'est pas toujours la même chose que "plus efficace". Je suppose que vous voulez dire "Si un programme devait être raccourci au détriment de la lisibilité".
Les programmes doivent être écrits pour que les gens puissent les lire, et seulement 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 pour qu'il soit court. Je dois cependant noter que raccourcir un programme le rend souvent plus lisible (il y a le seuil évident que vous atteignez lorsque votre code commence à ressembler à du bruit de ligne, mais jusque-là, exprimer quelque chose de plus succinctement semble le rendre plus clair).
Il y a des exceptions spécifiques (comme vos scripts Shell personnels ou un code de fusion de données) que personne n'aura jamais besoin de maintenir et que vous seul aurez besoin de lire. Dans cette situation, il est probablement acceptable de sacrifier une certaine lisibilité à l'opportunité tant que vous pouvez toujours la comprendre.
Parfois, oui.
La lisibilité est une bonne chose à rechercher. La plupart des codes écrits pour des applications métier typiques seront suffisamment performants et il est important de se concentrer sur la lisibilité. Dans des domaines plus exigeants en performances (comme la programmation de jeux vidéo ou le calcul intensif), il peut être important de renoncer à la lisibilité au profit de l'utilisation d'une fonctionnalité de langage particulière qui est horriblement illisible et pourtant incroyablement performante.
Pour un exemple de ce dernier, voir l'article Fast Inverse Square Root sur Wikipedia.
Je pense généralement qu'il est préférable de rendre quelque chose de lisible en premier et de s'inquiéter des performances après, à condition de prendre des précautions de bon sens comme ne pas choisir un algorithme O (n ^ 2) plutôt que O(n) sont prises. la lisibilité, par souci de concision seulement, est, à mon avis, peu judicieuse.
Je je l'ai cité avant , et je vais le citer à nouveau:
Rendez-le correct,
préciser,
soyez concis,
faites vite.Dans cet ordre.
La seule fois où je sacrifierais la lisibilité serait lorsque le code se révélerait être un goulot d'étranglement des performances et qu'une réécriture corrigerait cela. Dans ce cas, le intention du code doit être bien documenté afin que s'il y a un bug, il puisse être retrouvé plus facilement.
Cela ne veut pas dire que la réécriture doit être illisible bien sûr.
Devriez-vous sacrifier la lisibilité du code avec son efficacité?
En termes de code, il est toujours agréable d'être auto-documenté. Mais parfois, cela ne peut pas arriver. Parfois, vous devez optimiser et parfois ce code n'est pas en soi très lisible.
C'est pour cela que les commentaires ont été inventés. 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.
Il n'y a, à mon avis, absolument aucune excuse pour ne pas avoir quelques commentaires de base. De toute évidence, if ( x == 0 ) /* check if x is 0 */ est totalement inutile; vous ne devez 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.
Devriez-vous sacrifier la lisibilité du code avec son efficacité?
Si l'efficacité est votre objectif actuel (comme dans la phase d'optimisation) et vous savez - vous avez des mesures, n'est-ce pas? - cette ligne (s) de code est le goulot d'étranglement actuel, alors oui.
Sinon, non: la lisibilité vous permettra (ou à un autre) de pouvoir modifier ce code plus tard pour le rendre plus efficace, car il est plus facile à comprendre.
Personne ne gagne Code Golf
par exemple. 3 lignes de code en 1 ligne
Une idée particulièrement terrible.
Coût pour jouer au golf à code - très élevé.
Coût pour maintenir des programmes illisibles - astronomiques.
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 de l'algorithme et de la structure de données appropriés - élevée. L'utilisation des ressources est faible.
Efficacité insensée ("micro-optimisation")
Coût de jouer autour de la micro-optimisation - élevé.
Coût pour maintenir un code micro-optimisé illisible - très élevé.
La valeur de la micro-optimisation - varie. Lorsqu'il y a une valeur non nulle ici, les coûts l'emportent toujours.
Je n'accepte pas l'argument "lisibilité sur les performances". Permettez-moi de vous donner une réponse avec une rotation différente.
Quelques antécédents: vous savez ce qui me rend malade? Lorsque je double-clique sur Poste de travail et que je dois réellement attendre qu'il se remplisse. Si cela prend plus de 5 secondes, je suis vraiment frustré. Ce qui est stupide, et ne blâmez pas seulement Microsoft pour cela, c'est que dans certains cas, la raison pour laquelle cela prend si longtemps est qu'une décision doit être prise sur l'icône à afficher! C'est vrai. Je suis donc assis, uniquement intéressé à aller sur mon lecteur C: et je dois attendre que le pilote accède à mon CD-ROM et lise l'icône à partir de là (en supposant qu'il y ait un CD dans le lecteur).
D'ACCORD. Imaginez juste une seconde toutes les couches entre moi, double-cliquant sur Poste de travail et il parle réellement via des pilotes au CD-ROM. Imaginez maintenant que chaque couche était ... plus rapide ...
Vous voyez, derrière tout cela, il y a 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 la nuit en vous disant que vous avez fait la bonne chose en vous assurant que le code est plus lisible et pourtant plus lent. Même légèrement plus lent qu'il ne peut l'être. Et donc des milliers de développeurs font cela, 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: D'abord, faites-le fonctionner, puis accélérez-le.Toujours visez à é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 programmeur 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, le code lisible peut être expliqué alors que l'inefficacité est tout simplement inacceptable.
Cela dépend si nous parlons d'efficacité en termes de vitesse d'exécution du code ou d'efficacité dans la rapidité avec laquelle le développeur peut écrire le code. Si vous sacrifiez la lisibilité du code au profit de la possibilité de taper du code très rapidement, vous vous retrouverez probablement à payer le temps en arrière en termes de débogage.
Cependant, si nous parlons de sacrifier la lisibilité du code en termes de vitesse d'exécution du code, il s'agit probablement d'un compromis acceptable tant que le code doit s'exécuter de manière efficace. Écrire quelque chose qui s'exécute aussi vite que possible simplement parce que vous le pouvez n'est pas aussi bon que parce que c'est quelque chose comme racine carrée inverse rapide où la performance est la clé. L'astuce va être entre équilibrer le code et s'assurer que même si la source peut être difficile à lire, les commentaires décrivant ce qu'elle explique expliquent ce qui se passe.
Cette question m'est souvent venue à l'esprit lorsque les entretiens sont discutés au bureau. Il y a plusieurs années, en tant que diplômé, 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 pour l'intervieweur, c'était une question en noir et blanc, donc il n'y avait pas de compromis. Le processus devrait survivre à l'individu, car les gens vont et viennent plus que vifs et vous voulez préparer de nouveaux départs dès que possible, et plus le code est facile à lire, plus il est rapide de comprendre ce qui se passe.
J'ai lu un livre il y a quelque temps qui était plutôt bon, intitulé Domain Driven Development: Domain-driven Design: Tackling Complexity in the Heart of Software Certes, c'est un peu une lecture sèche au début, mais le matériel est bien présenté. Cela montre une bonne approche qui mène à des systèmes qui se documentent bien. La langue est le moyen de communiquer votre solution, donc plus la solution est claire, plus il est facile de l'adapter si la performance devient un facteur citique. C'est ma conviction et cela semble avoir bien fonctionné pour moi.
De nombreuses astuces, qui étaient censées rendre le code plus rapide, mais tendent à le rendre moins lisible, ne sont plus nécessaires, car soit les compilateurs sont devenus très intelligents (encore plus intelligents que la plupart des développeurs) ou les machines sont devenues ridicules rapidement .
Il est rare que le retour sur investissement pour rendre le code plus rapide au détriment de la lisibilité en vaille la peine. Les ordinateurs modernes fonctionnent si vite que je doute qu'il y ait un scénario où vous voudriez 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é à plusieurs reprises, le simple fait que le code soit lisible ne signifie pas nécessairement qu'il est plus lent.
Un bon exemple est un nom de variable: $a
Quel est $a ?? Ceci est hors contexte, vous ne pouvez donc pas répondre à cette question, mais avez-vous déjà rencontré cela dans du code réel? Supposons maintenant que quelqu'un a écrit $file_handle - maintenant qu'est-ce que c'est? C'est clair même hors contexte. La longueur du nom de variable fait une différence insignifiante pour l'ordinateur.
Je pense qu'il y a du bon sens à avoir ici.
Certaines applications peuvent justifier un raccourci de changement de bit que tout le monde ne comprendra pas, mais je pense qu'à un moment donné, les rendements sont diminués et trouver un scénario est rare *.
* cela dépend de l'industrie et d'autres choses. Je regarde cela du point de vue du développeur de logiciels d'entreprise (Business Information Systems).
Pour regarder cela sous un autre angle (mais pas pour divaguer), je travaille dans une entreprise qui fait du SAAS. Lorsqu'un site tombe en panne, nous devons le réparer très, très rapidement - généralement, quelqu'un d'autre corrige le code d'un autre développeur.
Je beaucoup plutôt que quelqu'un fasse quelque chose de très inefficace mais lisible plutôt que de le rendre sophistiqué et "rapide". Nos serveurs Web sont de pointe et une demande n'a pas besoin d'être livrée en millionièmes de seconde. Nous n'avons pas de problèmes de charge.
Donc, dans la pratique, je pense que vous êtes plus susceptible de vous blesser ou de blesser les autres ... (Je préfère avoir mon week-end de retour.)
Pour la plupart des cas, la réponse est "Faites confiance à votre compilateur pour faire son travail" et écrivez du code lisible. Cela implique que le code est structuré de manière logique (c'est-à-dire sans spaghetti) et auto-documenté (c'est-à-dire avec des noms suffisamment clairs de variables, de fonctions, etc.). Code supplémentaire qui n'est pas auto-documenté avec des commentaires significatifs. Ne commentez pas pour commenter, c'est-à-dire
x++; // Add one to x
Plutôt, commentez pour vous, le lecteur, dans 6 mois ou 12 mois ou dans un autre délai suffisamment long. Adoptez une norme de codage et suivez-la.
Le code propre est un code rapide. Le code clairement écrit et facile à entretenir a tendance à être plus rapide car c'est un indicateur que le programmeur a compris la tâche à accomplir et a remodelé le code jusqu'à son objectif principal.
De plus, 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. Lisez les compilateurs pour comprendre pourquoi c'est le cas.
Lorsque je travaille sur quelque chose basé sur les performances, comme les graphiques, je sacrifie parfois la lisibilité/maintenabilité lorsque je fais des choses comme le traitement d'image lorsque je travaille sur le plus profond des algorithmes imbriqués où de petites optimisations peuvent avoir un effet majeur. Et même alors, je ne le fais qu'après le profilage pour assurer que les changements en fait accélèrent les choses. Je ne peux pas vous dire combien de fois j'ai essayé des `` optimisations '' codées à la main pour constater que cela ralentissait réellement l'application en raison de la façon dont le compilateur optimisait le code tapé à la main.