Question

Je travaille sur un outil qui générera le code source d’une interface et quelques classes implémentant cette interface. Ma sortie n'est pas particulièrement compliquée, il ne sera donc pas difficile de la rendre conforme à nos normes de formatage de code habituelles.

Mais cela m'a fait réfléchir: à quel point le code généré automatiquement doit-il être lisible par l'homme? Quand faut-il déployer des efforts supplémentaires pour s'assurer que le code généré est facilement lu et compris par un humain?

Dans mon cas, les classes que je génère sont essentiellement des conteneurs pour certaines données liées à une autre partie de la construction avec des méthodes pour obtenir les données. Personne ne devrait jamais avoir besoin de regarder le code des classes elles-mêmes, il leur suffit d'appeler les différents accesseurs fournis par les classes. Donc, ce n’est probablement pas trop important si le code est "propre", bien formaté et facilement lisible par un humain.

Cependant, que se passe-t-il si vous générez du code contenant plus qu'une petite quantité de logique simple?

Était-ce utile?

La solution

Je pense qu'il est tout aussi important que le code généré soit lisible et respecte les styles de codage normaux. À un moment donné, quelqu'un devra soit déboguer le code, soit voir ce qui se passe "dans les coulisses".

Autres conseils

Oui !, absolument! Je peux même vous raconter une histoire pour expliquer pourquoi il est important qu’un humain puisse facilement lire le code généré automatiquement ...

Une fois, j’ai eu l’occasion de travailler sur un nouveau projet. Désormais, l’une des premières choses à faire lorsque vous commencez à écrire du code est de créer une sorte de connexion et une représentation des données depuis et vers la base de données. Mais au lieu d'écrire simplement ce code à la main, nous avons eu quelqu'un qui avait développé son propre générateur de code pour construire automatiquement les classes de base à partir d'un schéma de base de données. C’était vraiment bien, le travail fastidieux d’écrire tout ce code était maintenant hors de portée de notre main ... Le seul problème était que le code généré était loin d’être lisible par un humain normal .

Bien sûr, nous n’avons pas parlé de cela, parce qu’il nous a évité beaucoup de travail. Mais après un certain temps, les choses ont commencé à mal tourner, les données ont été mal lues à partir de l’entrée de l’utilisateur (du moins nous le pensions), des corruptions se sont produites à l’intérieur de la base de données alors que nous ne lisions que . Étrange… parce que la lecture ne change aucune donnée (encore une fois, nous pensions)…

Comme tout bon développeur, nous avons commencé à remettre en question notre propre code, mais après des jours de recherche ... même en réécrivant du code, nous n'avons rien trouvé ... et puis, nous nous sommes aperçus que le code généré automatiquement était défectueux!

Alors maintenant, une tâche encore plus importante nous attendait: vérifier le code généré automatiquement qu'aucune personne sensée ne pourrait comprendre dans un délai raisonnable ... Je parle de code de style non mis en retrait, très mauvais, avec des noms de variable et de fonction imprononçables. .. Il s'est avéré qu'il serait même plus rapide de réécrire le code nous-mêmes, au lieu d'essayer de comprendre comment le code fonctionnait réellement.

Finalement, le développeur qui a écrit le générateur de code l'a refait plus tard, de sorte qu'il génère maintenant du code lisible , au cas où quelque chose se passerait mal comme avant.

Voici un lien que je viens de trouver sur le sujet à traiter ; Je cherchais réellement un lien vers l’un des chapitres du "programmeur pragmatique". livre pour indiquer pourquoi nous avons d'abord examiné notre code.

Je pense que cela dépend de la manière dont le code généré sera utilisé. Si le code n’est pas destiné à être lu par les humains, c’est-à-dire qu’il est régénéré chaque fois que quelque chose change, je ne pense pas qu’il soit lisible. Toutefois, si vous utilisez la génération de code comme étape intermédiaire de la procédure "normale". programmation, le contenu généré devrait avoir la même lisibilité que le reste de votre code source.

En fait, rendre le code généré " illisible " peut être un avantage, car cela découragera les gens de "piratage informatique" code généré, et implémentez plutôt leurs modifications dans le générateur de code - ce qui est très utile lorsque vous devez régénérer le code pour une raison quelconque et ne pas perdre les modifications que votre collègue a apportées car il pensait que le code généré était "terminé".

Oui c'est le cas. Tout d’abord, vous aurez peut-être besoin de le déboguer - vous simplifierez la tâche. Deuxièmement, il convient de respecter les conventions de codage que vous utilisez dans votre boutique, car il se peut qu'un jour le code doit être modifié manuellement pour devenir ainsi un code humain. Ce scénario se produit généralement lorsque votre outil de génération de code ne couvre pas un élément spécifique dont vous avez besoin et qu’il n’est pas jugé utile de le modifier simplement à cette fin.

Recherchez la génération de code active et génération de code passif . En ce qui concerne la génération de code passif, absolument oui, toujours. En ce qui concerne la génération de code actif, lorsque le code atteint son objectif de transparence, ce qui se comporte exactement comme un document API, alors non.

Je dirais qu'il est impératif que le code soit lisible par l'homme, à moins que votre outil de code-gen ait un excellent débogueur que vous (ou un collègue malheureux) aurez probablement à la taille la plus profonde dans le code essayant de le suivre oh bug si insaisissable dans le système. Ma propre excursion dans le 'code from UML' m'a laissé un goût amer car je ne pouvais pas comprendre le processus de débogage supposé 'sophistiqué'.

L’intérêt du code généré est de faire quelque chose de "complexe". cela est plus facile à définir dans un langage de niveau supérieur. En raison de sa génération, la maintenance réelle de ce code généré doit se faire dans le sous-programme qui génère le code, pas le code généré.

Par conséquent, la lisibilité humaine devrait avoir une priorité plus basse; des choses comme la vitesse d'exécution ou la fonctionnalité sont beaucoup plus importantes. C'est particulièrement le cas lorsque vous examinez des outils tels que bison et flex, qui utilisent le code généré pour générer au préalable des tables de recherche rapides afin d'effectuer une correspondance de modèle, ce qui serait simplement insensé pour une maintenance manuelle.

Vous allez vous tuer si vous devez déboguer votre propre code généré. Ne commencez pas à penser que vous ne le ferez pas. N'oubliez pas que lorsque vous faites confiance à votre code pour générer du code, vous avez déjà introduit deux erreurs dans le système: vous vous êtes inséré deux fois.

Il n'y a absolument AUCUNE raison de ne pas le rendre analysable, alors pourquoi voudriez-vous le faire dans le monde?

-Adam

Un autre aspect du problème qui n’a pas été mentionné est que le code généré doit également être "compatible avec le contrôle des versions". (dans la mesure du possible).

J'ai trouvé utile de vérifier à plusieurs reprises les différences entre le code généré et le code source.

De cette façon, vous pourriez même parfois trouver des bogues dans les outils qui génèrent du code.

Il est tout à fait possible que, dans le futur, quelqu'un veuille voir ce que fait votre code. Le rendre compréhensible est donc une bonne chose.

Vous pouvez également inclure, en haut de chaque fichier généré, un commentaire expliquant comment et pourquoi ce fichier a été généré et à quoi il sert.

En règle générale, si vous générez du code qui doit être modifié par la suite, il doit être aussi lisible que possible. Cependant, même si c'est du code qui sera généré et ne sera plus jamais modifié, il doit tout de même être suffisamment lisible pour que vous (en tant que développeur écrivant le générateur de code) puissiez déboguer le générateur. Si votre générateur génère du mauvais code, cela risque d'être difficile traquer s'il est difficile à comprendre.

Je pense que cela vaut la peine de prendre le temps supplémentaire nécessaire pour le rendre lisible par l'homme, juste pour faciliter le débogage.

Le code généré doit être lisible (le format, etc., peut généralement être manipulé par un IDE à la moitié décent). À un certain stade de la vie des codes, quelqu'un le verra et ils voudront le comprendre.

Je pense que pour les conteneurs de données ou les objets au fonctionnement très simple, la lisibilité humaine n’est pas très importante.

Cependant, dès qu'un développeur doit lire le code pour comprendre comment quelque chose se passe, il doit être lisible. Et si la logique a un bug? Comment quelqu'un pourra-t-il le découvrir si personne ne peut lire et comprendre le code? J'irais même jusqu'à générer des commentaires pour les sections logiques plus complexes, afin d'exprimer l'intention, afin de déterminer plus facilement s'il existe vraiment un bogue.

La logique doit toujours être lisible. Si quelqu'un d'autre lit le code, essayez de vous mettre à sa place et voyez si vous comprenez parfaitement le code au niveau haut (et bas?) Sans lire ce morceau de code en particulier.

Je ne passerais pas trop de temps avec du code qui ne serait jamais lu, mais si ce n’est pas trop longtemps, je passerais en revue le code généré. Sinon, faites au moins des commentaires pour couvrir la perte de lisibilité.

Si ce code est susceptible d'être débogué, vous devriez sérieusement envisager de le générer dans un format lisible par l'homme.

Il existe différents types de code généré, mais les types les plus simples seraient:

  1. Code généré qui n'est pas destiné à être vu par le développeur. Par exemple, un code XML-ish qui définit les dispositions (pensez aux fichiers .frm ou aux fichiers horribles générés par SSIS)
  2. Le code généré est destiné à servir de base à une classe qui sera personnalisée par la suite par votre développeur. Par exemple, un code est généré pour réduire le problème de frappe

Si vous utilisez cette dernière solution, vous voudrez certainement que votre code soit lisible par l'homme.

Classes et interfaces, quelle que soit la méthode choisie "hors limites". aux développeurs que vous pensez qu'ils devraient être, tomberaient presque certainement sous le type de code généré numéro 2. Ils seront touchés par le débogueur à un moment donné - l'application de la mise en forme du code est le moins que vous puissiez faire, le processus de débogage est plus facile lorsque le compilateur frappe les classes générées

Comme presque tout le monde ici, je dis le rendre lisible. Cela ne coûte rien de plus dans votre processus de génération et vous (ou votre successeur) l'apprécierez quand ils vont creuser.

Pour un exemple concret, regardez tout ce que Visual Studio génère. Bien formaté, avec des commentaires et tout.

Le code généré est du code, et il n’ya aucune raison que tout code soit illisible et joliment formaté. C’est bon marché, surtout dans le code généré: vous n’avez pas besoin d’appliquer vous-même le formatage, le générateur le fait pour vous à chaque fois! :)

Comme option secondaire au cas où vous seriez vraiment trop paresseux, pourquoi ne pas canaliser le code avec un utilitaire d’esthétique de votre choix avant de l’écrire sur le disque pour assurer au moins un certain niveau de cohérence. Néanmoins, presque tous les bons programmeurs que je connais formulent leur code plutôt de manière pédante et il y a une bonne raison à cela: il n'y a pas de code en écriture seule.

Absolument oui pour des tonnes de bonnes raisons déjà mentionnées ci-dessus. En outre, si votre code doit être vérifié par un évaluateur (pour des problèmes de sécurité et de fiabilité), il est préférable de le remplacer par un code humain. Si ce n’est pas le cas, l’évaluateur refusera de l’évaluer et votre projet sera réaménagé par les autorités. La seule solution est alors d’évaluer ... le générateur de code (c’est généralement beaucoup plus difficile;))

Cela dépend si le code ne sera lu que par un compilateur ou également par un humain. De plus, il importe que le code soit supposé être ultra-rapide ou que la lisibilité soit importante. En cas de doute, faites un effort supplémentaire pour générer du code lisible.

Je pense que la réponse est: cela dépend.

* Cela dépend si vous devez configurer et stocker le code généré en tant qu'artefact. Par exemple, les utilisateurs conservent ou configurent rarement la sortie du code objet d'un compilateur c, car ils savent qu'ils peuvent le reproduire à partir de la source à chaque fois. Je pense qu'il peut y avoir une analogie similaire ici. * Cela dépend si vous devez certifier le code selon certaines normes, par exemple. Misra-C ou DO178. * Cela dépend si le code source est généré par votre outil à chaque compilation du code ou s'il sera stocké pour être inclus ultérieurement dans une construction.

Personnellement, si tout ce que vous voulez faire est de construire le code, de le compiler dans un exécutable puis de jeter le code intermédiaire, je ne vois pas l'intérêt de le rendre trop joli.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top