Est-il possible de rendre le code long représentant un calcul plus facile à lire?

9

Les méthodes longues sont généralement considérées comme mauvaises, mais dans mon code, j'ai des méthodes longues difficiles à comprendre (plus de 50 lignes). J'ai du mal à rendre ces méthodes plus faciles à lire, car une seule instruction à l'intérieur fait déjà plus de 50 lignes et cette instruction unique difficile à lire consiste à créer une requête de base de données à l'aide d'un ORM pour effectuer un travail spécifique là où le travail est effectué. clairement indiqué sur le nom de la méthode. La raison pour laquelle l'instruction est si longue car elle se joint à plusieurs colonnes, applique plusieurs emplacements et sélectionne plusieurs colonnes distinctes pour créer un format de sortie documenté requis.

Un tel code difficile à lire est-il considéré comme un mauvais code? De même, si j'écris du code pour un algorithme compliqué résultant en un code difficile à lire enveloppé dans une méthode clairement nommée, ce code est-il un mauvais code?

readability

— Michael Tsang
source

N'y a-t-il pas un moyen pour vous de paramétrer la requête d'une manière ou d'une autre? Je suppose que cette requête varie en fonction de ce qui se passe à l'intérieur de la méthode qui crée. Vous pouvez peut-être le diviser en petits morceaux et le construire en plusieurs étapes pour en faciliter la lecture.

— Zalomon

Votre ORM prend-il en charge les vues? Vous pouvez extraire une (groupe de) jointure dans une vue, puis sélectionner la vue. Même si la vue n'est pas utilisée ailleurs, cela peut aider à briser une grosse instruction SQL

— Caleth

Votre ORM prend-il en charge un langage de requête de type SQL? Si oui, vous pouvez déplacer la requête vers son propre fichier et activer la mise en surbrillance de la syntaxe IDE. Dans votre application, chargez la requête à partir du fichier. Si votre IDE ne prend pas exactement en charge ce langage de requête spécifique, vous pouvez vous entendre avec le formatage SQL même si ce n'est pas parfait. Cependant la lisibilité est largement augmentée par un bon formatage. Cela a également l'avantage qu'il est facile de copier la requête sur un bloc-notes et d'y apporter des modifications.

— SpaceTrucker

17

Tu as écrit

Un tel code difficile à lire est-il considéré comme un mauvais code

vous êtes donc tout à fait d'accord pour dire que c'est du code difficile à lire , et s'il est difficile à lire, il est difficile à maintenir et à évoluer - donc je suppose que vous considérez le code comme étant "mauvais" par vos propres mesures. Cependant, il n'est parfois pas évident de savoir comment améliorer quelque chose comme une instruction SQL de 50 lignes. Les refactorisations simples de la «méthode d'extraction» ne fonctionnent pas, et vous n'avez probablement aucune idée par où commencer pour rendre le code plus lisible. Pour ces cas, vous pouvez toujours essayer une ou toutes les solutions suivantes

montrez le code à quelqu'un d'autre qui est plus expérimenté que vous dans le nettoyage du code. Si vous ne pouvez pas demander à quelqu'un dans votre organisation, essayez codereview.stackexchange
essayez de google pour le problème spécifique. Pour votre exemple, des choses comme «nettoyer une instruction sql longue» pourraient être un bon début. Vous serez étonné du nombre d'articles que vous trouverez sur ce sujet, et même si vous ne trouvez pas de recette braindead pour votre cas, vous pourriez avoir de nouvelles idées
au lieu de demander une justification pour les choses que vous ne pouvez pas faire, concentrez-vous sur les choses que vous pouvez faire pour nettoyer le code au moins un peu, comme ajouter des sauts de ligne appropriés, une indentation appropriée, ajouter des commentaires explicatifs, améliorer certaines variables Nom. Il n'est pas improbable, au cours de ce processus, de vous forcer à relire les détails du code, vous trouverez un moyen de refactoriser le code en unités plus petites
pratique, pratique, pratique. Le "codage propre" n'est pas quelque chose que vous apprenez en une journée, il devient plus facile avec plus d'expérience. Peut-être que vous ne trouvez pas de solution à votre problème aujourd'hui, mais lorsque vous reviendrez au code dans quelques mois, il vous semblera différent.

— Doc Brown
source

Je suis un peu en désaccord avec la partie commentaire, s'il y a une partie complexe du code qui est complexe parce qu'il ne peut pas en être autrement ET n'a pas trouvé de moyen de le simplifier, les commentaires ne donneront probablement pas une vue d'ensemble de ce qui est fait. Le documenter avec un diagramme serait bien mieux. Et un commentaire faisant référence à cette documentation externe doit être laissé. Bien sûr, cette situation doit être exceptionnelle car nous savons tous que la maintenance de la documentation externe est rarement effectuée, donc moins il y en a, mieux c'est. Pour le reste, une bonne réponse comme toujours.

— Walfrat

@Walfrat: mon intention était de fournir une directive générale sur le processus, pas exclusivement pour "50 lignes de code SQL", et non pas comme une solution "prête à l'emploi" avec toutes les approches potentielles.

— Doc Brown

Je sais, je voulais juste suggérer que si quelque chose après avoir été revu plusieurs fois ne pouvait pas être suffisamment simplifié (quel qu'il soit), les commentaires ne contribueraient probablement pas à ce qui rend cette chose complexe, donc une documentation externe minimale sera probablement requise. Dans le cas spécifique des requêtes de base de données, cela est encore plus facile en affichant un diagramme qui montre comment chaque partie de la requête est en corrélation les unes avec les autres.

— Walfrat

4

Difficile à lire n'est pas mauvais - inutilement difficile à lire est mauvais.

Certaines choses sont tout simplement difficiles. Dans ce cas, vous devez comprendre complètement le problème, écrire le code et le commenter aussi bien que possible afin que le prochain développeur ait une chance.

Mais certaines choses ne sont difficiles que parce que vous les avez rendues difficiles. Si le problème peut être simplifié et rendu plus facile, simplifiez-le. S'il est difficile à comprendre mais peut être raisonnablement divisé en sous-problèmes, divisez-le en sous-problèmes pour le simplifier.

— gnasher729
source

Exactement. Faites de votre mieux pour rendre le code auto-documenté, puis utilisez les commentaires pour combler les lacunes. (édité: j'ai réalisé après avoir posté mon commentaire que l'OP faisait référence aux requêtes de base de données ORM, pas à SQL.)

— Kyle A

1

ORM pour créer un rapport? Sérieusement? Apprenez du SQL, mec. Les langages procéduraux sont terribles dans ce genre de choses.

SQL est un langage beaucoup mieux conçu pour gérer les jointures et les sélections compliquées. Et même si vous ne pouvez pas rendre le SQL beau, il existe toutes sortes d'outils de visualisation disponibles où vous pouvez faire glisser et déposer des objets de base de données sur un diagramme et le SQL sera généré pour vous. Sans oublier que vous serez en mesure de régler et d'optimiser la requête, d'afficher son plan de requête, de demander à la plate-forme de suggérer des options d'indexation supplémentaires, etc. C'est juste beaucoup plus flexible.

Je suis sûr que certaines personnes ici en désaccord avec moi, mais ORM n'est pas un bon moyen pour des rapports compliqués. Si possible, j'envisagerais de m'éloigner de cela et d'aller vers le langage de requête structuré .

— John Wu
source

2

Honnêtement, le fait que vous n'aimez pas les ORM est complètement hors de propos pour la question.

— Doc Brown

J'aime bien les ORM. Je déclare qu'ils ne sont pas un bon outil lorsque le code "joint sur plusieurs colonnes, applique plusieurs emplacements et sélectionne plusieurs colonnes distinctes pour créer un format de sortie documenté requis", qui est le sujet de ce fil.

— John Wu

0

En général, le code difficile à lire est une mauvaise idée n'importe où - même si vous êtes le seul responsable - j'ai eu plusieurs fois le retour à quelques années de code ou même des semaines plus tard et à avoir du mal à comprendre.

Si vous devez faire beaucoup de choses dans une seule requête, essayez de la diviser en plusieurs lignes avec des commentaires intégrés:

query(join(map(condition1, condition2), blah, blah, something(bah, blah, blah)))

Devient:

// Why are we doing such an awful single query rather than a sequence of selects?
query( // Description of query
  join( // Why are you doing a join here
    map( // Why a map
      condition1, // What is this
      condition2  // And this
   ), // End Map
   blah, // What, Why?
   blah, // What, Why?
   something( // What does this do?
      bah, // What, Why?
      blah, // What, Why?
      blah // What, Why?
      ) // End Something
   ) // End Join
) // End Query

— Steve Barnes
source

Je suis ambigu quant à votre exemple. les commentaires devraient expliquer pourquoi le code est tel qu'il est. Ce qui devrait être exprimé par les identifiants ...

— Timothy Truckle

@TimothyTruckle Je suis d'accord que les identifiants doivent clairement identifier ce qu'ils sont, mais trop souvent, ils ne sont pas clairs dans le code normal - dans le cas des noms de champs d'enregistrement, il y a souvent un manque de clarté en raison de contraintes historiques que j'ai rencontrées dans les cas où les noms de champs étaient limités à 5 caractères qui devaient tous être des lettres ASCII majuscules et ils ne pouvaient pas être modifiés en raison d'exigences de compatibilité, par exemple avec l'outil de rapport préféré des MD.

— Steve Barnes

0

En plus de l'excellente réponse de @ DocBrown, je pense qu'il vaut la peine de reconnaître que personne n'écrit du "bon" code tout le temps. Le codage fait des compromis, et il est souvent préférable d'accepter que vous avez écrit quelque chose d'un peu moins propre que vous ne le souhaiteriez et d'y revenir plus tard. La refactorisation est le processus d'amélioration du code au fil du temps - et d'après mon expérience, c'est ce qui fait une bonne base de code, et non pas «faire les choses correctement du premier coup».

Et vous évaluez le code au niveau de l'application, pas au niveau des méthodes / lignes de code individuelles. Donc, si vous avez une méthode complexe, mais qu'elle est clairement nommée, je ne pense pas que vous ayez un "mauvais" code tant que la méthode est cohérente.

La dénomination est la plus grande arme dont vous disposez pour rendre le code intelligible - donnez à votre méthode un nom qui permet aux gens qui lisent votre code de sauter le corps s'ils en ont besoin. Nommez vos variables, etc. de manière à ce que les lecteurs puissent voir ce qu'ils représentent sans avoir à lire leurs instructions d'affectation.

La prochaine chose est de vous assurer que votre méthode ne fait qu'une seule chose - les effets secondaires rendent le code difficile à comprendre. Donc, si votre méthode renvoie des données pour un format de sortie, elle ne doit pas également mettre à jour le statut de votre base de données sur "imprimé", ou autre chose.

La superposition / composante est la prochaine chose que vous pourriez faire - si vous avez un tas de méthodes complexes qui génèrent des résultats ORM, regroupez-les afin que les lecteurs de votre code puissent supposer qu'ils se comportent tous de la même manière, n'ont aucun effet secondaire, etc.

— Neville Kuyt
source