it-swarm-fr.com

Que signifie écrire un "bon code"?

Dans cette question, j'ai demandé si être un mauvais écrivain vous empêchait d'écrire du bon code. Beaucoup de réponses ont commencé par "cela dépend de ce que vous entendez par un bon code".

Il semble que les termes "bon code" et "mauvais code" soient très subjectifs. Puisque j'ai un point de vue, il peut être très différent de celui des autres.

Alors qu'est-ce que cela signifie d'écrire "bon code"? Qu'est-ce qu'un "bon code"?

41
gablin

Un bon codeur est comme un bon joueur de billard.

Quand vous voyez un joueur de billard professionnel, vous ne serez peut-être pas impressionné au début: "Bien sûr, ils ont obtenu toutes les balles, mais ils n'ont eu que des tirs faciles!" C'est parce que, quand un joueur de billard fait son tir, elle ne pense pas à quelle balle ira dans quelle poche, elle pense également à l'endroit où la balle de queue se retrouvera . La mise en place pour la prise de vue suivante nécessite des compétences et une pratique considérables, mais cela signifie également que cela semble facile.

Maintenant, en apportant cette métaphore au code, n bon codeur écrit un code qui semble facile et simple à faire. Beaucoup d'exemples de Brian Kernighan dans ses livres suivent ce modèle. Une partie du "truc" consiste à trouver un conceptualisation correcte du problème et de sa solution. Lorsque nous ne comprenons pas assez bien un problème, nous sommes plus susceptibles de trop compliquer nos solutions et nous ne parviendrons pas à voir des idées unificatrices.

Avec une bonne conceptualisation du problème, vous obtenez tout le reste: lisibilité, maintenabilité, efficacité et exactitude. Parce que la solution semble si simple, il y aura probablement moins de commentaires, car aucune explication supplémentaire n'est nécessaire. Un bon codeur peut également voir la vision à long terme du produit et former ses conceptualisations en conséquence.

91
Macneil

WTF's per minute

( original )


EDIT: L'idée de base est que la "qualité du code" ne peut pas être mise dans des règles, de la même manière que vous ne pouvez pas mettre du "bon art" ou de la "bonne poésie" dans les règles afin que vous puissiez laisser un ordinateur déterminer dire "oui, du bon art" ou "Non, mauvaise poésie". Actuellement, le seul moyen est de voir à quel point le code est facilement compréhensible pour les autres humains.

49
user1249

Il n'y a vraiment aucun bon critère autre que la vitesse à laquelle vous pouvez comprendre le code. Vous rendez votre code beau en trouvant le compromis parfait entre succinctness et la lisibilité.

Le "WTF par minute" (ci-dessus) est vrai mais ce n'est qu'un corollaire de la règle plus générale. Plus il y a de WTF, plus la compréhension est lente.

7
mojuba

Vous savez que vous écrivez du bon code quand ...

  1. Le client est content
  2. Collègues de travail empruntent votre code comme point de départ
  3. Le tout nouveau gars/fille vient de dire qu'il devait apporter des modifications à un système que vous avez construit il y a 6 mois et il/elle ne vous a jamais posé une seule fois une question
  4. Votre patron vous demande de développer de nouveaux widgets à utiliser par l'équipe
  5. Vous regardez le code que vous écrivez aujourd'hui et vous vous dites "J'aimerais avoir écrit du code comme ça il y a deux ans"

Comment mesurez-vous si le code est bon ...

  • Quel est le temps de réponse?
  • Combien de voyages aller-retour vers le serveur fait-il?
  • Souhaitez-vous utiliser personnellement l'application ou pensez-vous que c'est maladroit?
  • Pourriez-vous le construire de la même manière la prochaine fois?

Un bon code fonctionne quand il est censé le faire. Un bon code peut facilement être modifié en cas de besoin. Un bon code peut être réutilisé pour réaliser un profit.

Un code qui est

  1. sans bug

  2. réutilisable

  3. indépendant

  4. moins complexe

  5. bien documenté

  6. facile à changer

est appelé bon code.

Un bon programme fonctionne parfaitement et n'a pas de bugs. Mais quelles qualités internes produisent une telle perfection?. Ce n'est pas un mystère, nous avons juste besoin de quelques rappels occasionnels. Que vous codiez en C/C++, C #, Java, Basic, Perl, COBOL ou ASM, toutes les bonnes programmations présentent les mêmes qualités séculaires: simplicité, lisibilité, modularité, superposition, design, efficacité, élégance et clarté efficacité, élégance et clarté

Source: MSDN

4
Chankey Pathak

Cela vous semble-t-il familier?

Philips m'a donné l'occasion de regarder la conception d'un nouveau produit. Au fur et à mesure de son évolution, je suis devenu de plus en plus mal à l'aise et j'ai commencé à confier mes préoccupations à mon superviseur. Je lui ai dit à plusieurs reprises que les dessins n'étaient pas "propres" et qu'ils devaient être "beaux" de la même manière que les dessins de Dijkstra étaient beaux. Il n'a pas trouvé cela utile. Il m'a rappelé que nous étions des ingénieurs, pas des artistes. Dans son esprit, j'exprimais simplement mon goût et il voulait savoir quel critère j'utilisais pour porter mon jugement. Je n'ai pas pu lui dire! Parce que je ne pouvais pas expliquer quels principes étaient violés, mes commentaires ont simplement été ignorés et le travail a continué. Sentant qu'il devait y avoir un moyen d'expliquer et de motiver mon "goût", j'ai commencé à essayer de trouver un principe qui distinguerait les bons designs des mauvais. Les ingénieurs sont très pragmatiques; ils peuvent admirer la beauté, mais ils recherchent l'utilité. J'ai essayé de trouver une explication de la raison pour laquelle la "beauté" était utile.

Veuillez voir le reste ici .

3
mlvljr

en dehors des critères de qualité du code naturel (copier/coller minimum, pas de spaghetti, etc.) un bon code industriel doit toujours avoir l'air un peu naïf, un peu trop verbeux, comme

int key = i;
const bool do_not_create = false;
Record r = cache.get(key, do_not_create);
++i;

par opposition à

Record r = cache.get(i++, false);
1
bobah

Peut-être qu'une réponse en illustrant le contraire aiderait (en plus c'est une excuse pour obtenir XKCD ici).

alt text

Un bon code est

  • simple à comprendre,
  • facile à maintenir,
  • n'essaie pas de résoudre tous les problèmes seulement celui à portée de main
  • vit longtemps sans que les développeurs recherchent des alternatives

Les exemples comprennent

  • Apache Commons
  • Cadre Spring
  • Cadre Hibernate
1
Gary Rowe

Je vais simplement aller avec "maintenable"

Tout le code doit être maintenu: pas besoin de rendre cette tâche plus difficile que nécessaire

Si un lecteur ne comprend pas cette simple exigence ou a besoin qu'elle soit expliquée, alors ce lecteur ne devrait pas écrire de code ...

1
gbn

Un bon code va être différent pour chaque personne et la langue avec laquelle ils travaillent a également un impact sur ce qui pourrait être considéré comme un bon code. Généralement, lorsque j'aborde un projet, je recherche les éléments suivants:

  • Comment le projet est-il organisé? Les fichiers source sont-ils organisés de manière propre et puis-je trouver du code sans trop d'effort?
  • Comment le code est-il organisé? Est-il clairement documenté ce que fait le code dans le fichier, par exemple en utilisant un en-tête de fichier ou en utilisant chaque classe résidant dans son propre fichier? Y a-t-il des fonctions dans le fichier qui ne sont plus utilisées dans l'application?
  • Comment les fonctions sont-elles organisées? Existe-t-il un modèle clair indiquant où les variables sont déclarées, ou s'agit-il d'un modèle assez aléatoire? Le code a-t-il un flux logique et évite-t-il les structures de contrôle inutiles? Tout est-il clairement documenté, le code étant auto-documenté là où c'est nécessaire et les commentaires expriment clairement le pourquoi et/ou le comment de ce code?

Au-delà de tout cela, la conception de l'application a-t-elle un sens dans son ensemble? Le code résidant dans l'application peut être le meilleur au monde, mais il peut être difficile de travailler avec si la conception globale de l'application n'a aucun sens.

1
rjzii

Permettez-moi de bien vouloir ne pas être d'accord sur la lisibilité. Non, pas complètement: un bon code doit être lisible, et cela peut être facilement réalisé avec suffisamment de commentaires.

Mais je considère deux types de WTF: ceux où vous vous demandez si le programmeur est allé plus loin que la programmation 101, et ceux où vous ne comprenez absolument pas la gentillesse du code. Certains codes peuvent sembler très étranges au début, mais sont en fait une solution très inventive à un problème difficile. Le second ne doit pas compter dans le compteur WTF et peut être évité par des commentaires.

Un code très lisible peut être très, très lent. Une solution moins lisible peut améliorer la vitesse de plusieurs fois. R est un excellent exemple d'une langue où cela est souvent vrai. On aime éviter autant que possible les boucles for. En général, je considère que le code le plus rapide est le meilleur, même s'il est moins lisible. Autrement dit, si l'amélioration est substantielle bien sûr, et suffisamment de commentaires sont insérés pour expliquer ce que fait le code.

De plus, la gestion de la mémoire peut être cruciale dans de nombreuses applications scientifiques. Le code qui est très lisible a tendance à être un peu bâclé dans l'utilisation de la mémoire: il y a juste plus d'objets créés. Dans certains cas, une utilisation intelligente de la mémoire rend le code encore moins lisible. Mais si vous jonglez autour de gigaoctets de séquences d'ADN par exemple, la mémoire est un facteur crucial. Encore une fois, je considère que le code nécessitant moins de mémoire est le meilleur code, quelle que soit la lisibilité.

Alors oui, la lisibilité est importante pour un bon code. Je connais l'adagium d'Uwe Liggis: penser que ça fait mal et les ordinateurs sont bon marché. Mais dans mon domaine (génomique statistique), les temps de calcul d'une semaine et l'utilisation de la mémoire de plus de 40 Go ne sont pas considérés comme anormaux. Une amélioration de deux fois la vitesse et la moitié de la mémoire vaut donc beaucoup plus que ce peu de lisibilité supplémentaire.

1
Joris Meys

En ce qui me concerne ... Je sais que j'écris du bon code lorsqu'un collègue qui travaille sur un autre projet arrive et est capable d'intervenir et de comprendre ce que je fais sans que je passe en revue chaque bloc de code et montrer ce qu'il fait.
Au lieu de lui dire: "Attendez une minute, quoi?!" Il dit: "Oh, ok, je vois ce que tu as fait là-bas."

Un bon code n'a pas non plus beaucoup de solutions de contournement sournoises ou de "hacks". Des lignes où, pendant que vous l'écrivez, vous vous dites aussi: "Je sais que ce n'est pas une bonne façon de le faire, mais je vais devoir le faire de cette façon pour l'instant. Je rappellerai moi-même pour l'améliorer plus tard ... "

1
chiurox

Il existe de nombreuses fonctionnalités d'un "bon" code, mais les plus importantes, à mon humble avis, sont la lisibilité et la maintenabilité.

Votre code sera contiendra des bogues, probablement sera étendu et réutilisé, et devrait être refactorisé à un moment donné - même s'il Si vous le revisitez, il y a de fortes chances que vous n'ayez aucune idée de ce que vous avez fait en premier lieu, de vous faire une faveur et de ne mettre aucune barrière sur le chemin.

Bien sûr, utilisez cet algorithme complexe mais efficace, mais assurez-vous de passer un peu de temps supplémentaire à le documenter, mais sinon, rendez votre code clair et cohérent.

1
cjmUK