Comment définissez-vous un code élégant?
Duplicata possible:
Qu'est-ce que cela signifie d'écrire "bon code"?
Dans une discussion sur la qualité du codage et comment vous l'identifiez, je suis tombé sur une discussion sur le test de la capacité de codage des gens en leur faisant montrer comment ils échangeraient deux valeurs en utilisant un morceau de code pour atteindre l'objectif. Deux solutions clés ont été produites:
- Introduisez une variable de rechange pour faire passer la parcelle des valeurs ou:
- Utilisez des opérateurs au niveau du bit.
Il s'ensuit alors un argument sur lequel est en fait la meilleure solution (je pencherais pour la première option tout en étant conscient que la seconde existe, mais peut ne pas toujours être évaluée comme prévu en fonction des valeurs en question).
En gardant à l'esprit l'histoire de Mel the Real Programmer , je suis intéressé à savoir comment vous évaluez le code comme étant élégant ou non, et la concision est une caractéristique clé du code élégant.
Un bon code doit être propre, simple et facile à comprendre avant tout. Plus c'est simple et propre, moins il y a de chance que des bugs se glissent. Comme l'a inventé Saint-Exupéry, "La perfection est atteinte, non pas quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à emporter. "
De plus, un code élégant est généralement le résultat d'une analyse minutieuse du problème, et de la recherche d'un algorithme et d'une conception qui simplifie considérablement le code (et l'accélère souvent aussi). Par exemple. Programming Pearls montre plusieurs exemples où un aperçu obtenu pendant l'analyse a donné un angle d'attaque totalement différent, résultant en une solution très simple, élégante et courte.
Montrer à quel point l'auteur est intelligent ne vient qu'après ceux-ci ;-) La micro-optimisation des performances (comme l'utilisation des opérations au niveau du bit que vous mentionnez) ne doit être utilisée que lorsque l'on peut prouver (avec des mesures concrètes) que le morceau de code en question est le goulot d'étranglement , et que le changement améliore réellement les performances (j'ai vu des exemples contraires).
Le code élégant est une combinaison de:
- Exactitude. À mon humble avis, aucun mauvais code ne peut vraiment être élégant.
- Concision. Moins de code signifie moins de se tromper, moins de comprendre *.
- Lisibilité. Plus il est facile de comprendre le code, plus il est facile à maintenir.
- Performance. Vers un point. Un code prématurément pessimisé ne peut pas vraiment être élégant.
- Suivre les normes établies de la plateforme ou du projet. Lorsqu'on lui donne deux options tout aussi élégantes, celle qui se rapproche le plus de la norme établie est la meilleure.
- Exactement comme je le ferais. D'accord, je plaisante, mais il est facile d'étiqueter le code qui n'est PAS comme vous le feriez comme "inélégant". Veuillez ne pas le faire - gardez l'esprit ouvert à un code différent.
Bien sûr, il y a aussi le vrai adage bien trop souvent vrai: "Pour chaque problème, il existe une solution simple, élégante et erronée".
* Comme le montrent les commentaires ci-dessous, il existe une certaine controverse sur le code plus court. "Succinct" ne signifie pas "en autant de caractères que possible", il signifie "Brièvement et clairement exprimé".
Le code simple est un code si lisible que même les programmeurs débutants peuvent déterminer (au moins généralement) ce que fait le code. (Voir: Syntaxe d'expression Ruby )
Un code d'une complexité impressionnante est un code qui fait autant que possible en aussi peu de lignes que possible, sans vraiment se soucier de la lisibilité (Voir: Perl )
Le code élégant est un code qui fait dire aux autres développeurs "Oh mec, pourquoi n'y ai-je pas pensé?!" C'est en quelque sorte entre les deux premiers, avec du code qui peut ne pas être si évident que vos parents peuvent le lire, mais pas un gribouillage arcanique qui nécessite un codex pour interpréter. Il fait le travail, le fait enfin, et ne laisse pas les gens qui maintiennent le code se gratter la tête.
Fred Brooks décompose la complexité d'une solution en catégories de "complexité essentielle" et "complexité accidentelle" . Un code parfaitement élégant, pour moi, est celui qui est tout "complexité essentielle", et non "complexité accidentelle". L'astuce est que différents programmeurs auront des idées différentes sur ce qui est "complexe", nous sommes donc susceptibles de ne pas être d'accord sur l'élégance d'un peu de code.
Par exemple, je trouve que la structure du code LISP est beaucoup plus élégante que la structure du code dans les langages de type C. D'un autre côté, la notation de préfixe de LISP et la construction explicite de l'arbre d'analyse violent notre intuition sur la façon dont les expressions mathématiques devraient ressembler, ce qui peut rendre la lecture du code LISP plus difficile pour les gens. En conséquence, de nombreux programmeurs considèrent que toutes ces parenthèses dans LISP ne sont pas du tout "élégantes", mais en fait plutôt laides. Pour quelqu'un qui est vraiment préoccupé par la façon dont le compilateur interprétera le code, LISP peut sembler élégant. Pour quelqu'un qui est plus préoccupé par la façon dont les gens interpréteront le code, LISP peut sembler laid.
Le caractère succinct est un élément important, mais pour moi, pour être qualifié d'élégant, le code doit également être facilement compréhensible au point que vous dites: "Bien sûr, c'est la façon la plus évidente de le faire!" Même si paradoxalement ce n'est pas la première façon de penser. S'il ne réussit pas ce test, il peut être qualifié de "intelligent" ou "efficace", mais pas élégant.
C'est semblable à la poésie, qui est un langage élégant.
Les poètes peuvent dire en très peu de mots ce qu'il faudrait aux autres pages, et aux pages, à dire et pas aussi bien. Les codeurs élégants peuvent faire de même avec le code.
Un exemple typique compare une implémentation typique de quicksort en C avec quicksort dans Haskell:
quicksort :: Ord a => [a] -> [a]
quicksort [] = []
quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
where
lesser = filter (< p) xs
greater = filter (>= p)
(de plus en plus petit peut être aligné pour une solution à trois lignes).
Le XOR swap est assez bien connu. Et tout le monde, qui a au moins un peu de l'humilité demandée par Dijkstra vous le dira, c'est la mauvaise façon de faire les choses. Non seulement il est plus difficile de lire pour les humains, mais aussi pour les compilateurs. Les compilateurs sont relativement bons pour l'analyse des flux et l'allocation des registres et toutes sortes de choses. Ayant un bon compilateur, vous ne pouvez pas vous attendre à ce que chaque variable que vous créez existera réellement sur la pile/dans un registre à tout moment. Ce que vous devez faire est d'exprimer clairement les choses. Dans un langage qui prend en charge l'appel par référence, c'est la façon de procéder: swap(x, y);.
C'est la meilleure solution (j'ose le dire, au moins compte tenu des alternatives que vous avez fournies). C'est une déclaration one et elle s'explique d'elle-même. Il n'utilise pas le vaudou comme le fait le swap XOR. Il n'introduit pas le bruit d'une variable temporaire et de 3 instructions d'affectation. C'est quelque chose qui se produit dans le swap. En supposant qu'il s'agit d'une fonction, un compilateur décent insérera cet appel. Vous pouvez également en faire une macro.
Ce qui rend le code vraiment élégant, c'est le manque de redondances, l'orthogonalité, la simplicité. Il garantit des systèmes robustes qui se développent les uns sur les autres. Le fait d'avoir des groupes d'instructions récurrents partout où vous voulez un échange introduit la redondance, manque d'orthogonalité et manque de simplicité.
Il est facile de repérer ce que fait un code élégant. Vous obtenez le "Pourquoi n'ai-je pas pensé à ça?" vibe. Cela dépend de la complexité du problème et de la langue utilisée.
Cela ne signifie pas que la meilleure ou la plus simple solution soit automatiquement élégante. La simplicité est souvent l'une de ses qualités. Les modifications, bien que généralement plus faciles, ne maintiennent pas toujours l'élagance.
J'aime comparer le code avec les médias imprimés ici.
Vous savez que vous détestez quand vous lisez des articles trop simplifiés. Abasourdi. Peu de faits, des phrases simples. Cela se traduit par du code que je lie aux débutants: trivial, même naïf, implémentation, rien n'est trop compliqué, mais c'est long et plein d'étapes inutiles.
D'un autre côté, vous connaissez ce style de tour en ivoire. Vous lisez un livre de philosophes bien connus. Vous lisez un article scientifique sur une question compliquée: le style semble souvent être très long. Les mots ne sont pas réutilisés, vous devez montrer que vous pouvez connaître une douzaine de synonymes. Bien que le contenu réel puisse être pur, bon, intéressant - le style d'écriture est difficile à suivre. Ce style brouille la ligne de pensée originale. C'est intelligent code.
Le code élégant est quelque part au milieu et tout aussi subjectif que les préférences peuvent l'être. Vous pouvez facilement repérer et décrire les mauvais cas, mais la perfection est différente pour la plupart d'entre nous.
Bon est l'absence de Bad. Il s'applique à tout dans la vie et le code ne fait pas exception. Donc,
Un bon code est celui qui n'a pas d'odeur! Il est donc important pour vous de voir et de comprendre ce qu'est une odeur de code. Pas de blague.
Pensez-y. Vous dites que vous êtes heureux uniquement parce que vous n'êtes PAS triste ou que vous avez été débarrassé de votre tristesse. De même, vous appelez quelque chose un bon code, quand vous ne voyez rien de mauvais dans le code. Chaque aspect de qualité du code (maintenabilité, lisibilité, etc.) peut être atteint en se débarrassant de l'odeur du code. Et croyez-le ou non, cela ne se produit pas la première fois - cela se produit de manière itérative :)
L'élégance est la minimisation de la complexité. Si vous pouvez rapidement remettre le code à un autre programmeur ayant des compétences raisonnables et qu'il est capable de continuer le travail (et, espérons-le, à la hauteur de sa norme initiale), le code est probablement élégant.
Un logiciel bien écrit devrait rester en place pendant au moins dix ans. L'élégance initiale peut être effrayée par les hacks ultérieurs, mais la durée de survie du code est souvent une mesure raisonnable de la façon dont il a été initialement écrit. Le code mal écrit stagne (et les gens le piratent) ou est retravaillé (bien que dans la pratique, j'ai vu des gens remplacer un code élégant par des solutions moins importantes parce qu'ils ne l'ont pas examiné attentivement).
Ma définition est simple, malheureusement, vous ne pouvez pas la déterminer vous-même.
Code élégant présente les caractéristiques suivantes:
- Cela résout le problème.
- Je peux faire confiance aux tests de telle sorte que si je modifie un comportement, un test sera interrompu.
- Lorsque je ou + tout autre développeur + ouvre le code, il est immédiatement facile à suivre. Tout bloc logique non trivial est décrit par un commentaire.
- Les choses simples sont simples, les choses difficiles sont possibles.
- Quelqu'un d'autre est + disposé + à reprendre le développement du code même si je suis toujours là. Sans être forcé.
Le code élégant n'est pas le même que le design élégant bien qu'il y ait un croisement entre les 2.
Comment définissez-vous une peinture élégante? Il est beau à regarder, parfaitement lisible, il est parfaitement logique d'être facilement entretenu et fait juste le travail.
Un design élégant contribue à un code élégant. Vous ne pouvez pas avoir un code élégant sans un bon design mais vous pouvez avoir un code laid avec un bon design. Il vaut bien mieux écrire si can_can_add_apples_to_my_basket (20) puis add_apples_to_basket (20) else render_not_enough_room_to_add_apples (20) fin, puis écrivez les 2 conditions if qui seraient potentiellement réutilisables où vous en avez besoin pour tout ce dont vous avez besoin (c'est le bit de conception)
code qui sais si b.count + 20 <= b.max puis b + = 20 else raise ("trop de pommes") end
Vous avez toujours les 2 méthodes (count et max) donc vous avez toujours un bon design mais le code est moche et vide de sens, difficile à maintenir sans connaissance du système et totalement ambigu
Pour être honnête, il y a rarement une bonne raison d'échanger la valeur de deux variables, et ce n'est pas vraiment une chose "élégante" à faire, peu importe comment vous le faites.
Le code élégant ne concerne pas le code en lui-même, il s'agit vraiment de quoi le code fait et comment il le fait. Personnellement, je pense que c'est un mauvais exemple pour déterminer ce qu'est un "code élégant", car la chose qui se fait n'est pas elle-même élégante. Je trouve que le code Haskell est généralement élégant, car il (pour la plupart) traite de valeurs immuables. Cependant, les algorithmes utilisant l'état mutable peuvent également être écrits avec élégance (et ne semblent généralement pas si chauds dans Haskell).
Dans quelle mesure la plupart des développeurs peuvent-ils le lire? Est-il facile de le changer?
En conséquence, je serais certainement d'accord avec vous que l'opton 1 est beaucoup plus élégant.
L'option 2 est intelligente et montre une bonne connaissance des opérateurs. Il enregistre également un très petit morceau de mémoire. Utile, peut-être, dans des cas exceptionnels, et vaut bien qu'un développeur puisse le faire. Mais pas dans votre cas moyen à 99%.
Il devait être cohérent. Il devait y avoir ne sorte de modèle dedans. Et lorsque vous avez besoin de briser ce modèle, cassez-le de manière cohérente, de sorte que, globalement, il y ait encore une sorte de modèle.
Si quelqu'un pointe votre code et vous demande pourquoi le faites-vous de cette façon, et votre réponse est "Je ne sais pas, je le fais simplement de cette façon parce que c'est comme ça que je ' on m'a appris/parce que c'est comme ça que tout le monde fait " alors ce code peut être élégant ou pas élégant . Cependant, si vous pouvez expliquer pourquoi le code est ainsi, pourquoi l'aviez-vous choisi de le coder de cette façon, pourquoi les autres alternatives ne sont-elles pas aussi attrayantes, alors vous pouvez être sûr que le code est élégant .
J'étais blasé dans mon commentaire en haut, mais pour moi le code élégant est celui qui affecte mes sens beaucoup plus que la plupart.
Il produit une réaction positive dans la réalisation des objectifs tout en étant court et direct, simplicité mais avec un but et une puissance, élégant, symétrique et un peu "hors des sentiers battus" dans l'approche. Cela entraîne un élément de surprise. La méthode et l'algorithme ne sont pas si complexes (au moins superficiellement) qu'ils gênent sa compréhension.
Le code élégant est plus que la somme de ses parties. Parfois, un code élégant semble presque fonctionner avec les données, se plier avec elles, au lieu d'utiliser la force brute ou de mapper les données dans une autre forme. Pour moi, l'élégance vient souvent dans un emballage autonome - une seule fonction, peu ou pas d'appels externes, ni trop longs ni trop courts.
Par exemple, j'ai vu des méthodes de tri que j'appellerais élégantes. Et des codes/algorithmes élégants pour dessiner des fractales de manière inhabituelle mais très efficace - combinant la beauté visuelle et l'élégance du codage!
Le code élégant utilise l'intelligence pour accomplir quelque chose en beaucoup moins de code que la plupart des gens ne le penseraient, mais d'une manière lisible et évidente et qui ne ressemble pas à du golf de code.
Cela dépend vraiment de qui vous demandez. Une personne issue d'un milieu mathématique préférera souvent un code qu'un programmeur expérimenté peut trouver problématique. Cela semble très subjectif.
De plus, vous constaterez que différentes langues ont différentes manières de résoudre le même problème. En Python, par exemple, l'échange de deux variables est trivial: x, y = y, x
Dans la pratique, la plupart des programmeurs conviendraient qu'il existe des critères communs:
- le code élégant doit être aussi court que possible
- mais aussi verbeux que nécessaire
- il doit être facile à suivre
- chaque énoncé doit être facile à comprendre
- aucune déclaration ne doit paraître redondante ou superflue
- le code doit suivre les idiomes de la langue
- il ne doit pas utiliser d'abstractions qui fuient
Il s'agit d'une vision très pragmatique de l'élégance. Le code ne doit pas être "intelligent" ou il ne répond pas à ces critères. Mais il sera maintenable et plus facile à régler et à étendre.
Cela dit, il y a du code qui peut être une œuvre d'art malgré l'échec absolu de la plupart des règles de cette liste. Le code "intelligent" tombe souvent dans cette catégorie. Il est très dense, repose souvent sur une compréhension approfondie des implémentations sous-jacentes (disons, la gestion de la mémoire ou l'implémentation exacte du compilateur) mais évoque néanmoins une fascination sublime.
Il y a une différence entre l'élégance que vous trouveriez dans les scripts Yet Another Perl Hacker et le code que vous voudriez réellement utiliser dans la production. C'est la raison pour laquelle vous ne voudriez jamais que Mel soit dans votre équipe, même si vous pourriez appeler son opus majeur élégant.
Personnellement, je trouve que le code élégant est surfait. Mais je travaille dans le monde des bases de données où le code performant est d'une importance critique et le code "élégant" dans le contexte du code SQL le plus souvent (du moins d'après mon expérience) fonctionne mal. Je grince des dents à chaque fois que j'entends quelqu'un qui veut écrire du code SQL élégant.
En général cependant, je pense toujours que rechercher l'élégance est ridicule. En premier lieu, personne ne peut le définir correctement. Ce que vous voulez, c'est un code qui fonctionne correctement, fonctionne bien, soit maintenable, puis élégant est un quatrième très éloigné s'il fait même la liste.
Comprendre un code élégant devrait être comme résoudre un puzzle. Cela devrait être difficile à comprendre au début, puis très facile à comprendre une fois que vous l'avez "compris".
Il y a un compromis: les gens qui ne le comprennent pas se grattent la tête, tandis que ceux qui le comprennent le trouvent évident, rétrospectivement.
Quant à l'échange de variables, aucune ne sera particulièrement élégante. Il n'y a aucune complexité à apprivoiser ici, donc il n'y a pas de place pour une solution "élégante".