Qu'est-ce que cela signifie d'écrire «bon code»? [fermé]

Dans cette question, j'ai demandé si le fait d'être un mauvais écrivain vous empêche d'écrire un bon code. La plupart des réponses ont commencé avec "cela dépend de ce que vous entendez par bon code".

Il semble que les termes "bon code" et "mauvais code" soient très subjectifs. Puisque j'ai un point de vue, cela 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"?

Un bon codeur est comme un bon joueur de billard.

Quand vous voyez un joueur professionnel de billard, vous ne serez peut-être pas impressionné au début: "Bien sûr, ils ont toutes les balles dedans, mais ils n'ont eu que des tirs faciles!" En effet, quand une joueuse de billard fait son coup, elle ne pense pas à quelle balle ira dans quelle poche, elle pense aussi à la destination de la bille blanche . La préparation pour le prochain coup demande une habileté et une pratique extraordinaires, mais cela signifie également que cela semble facile.

Maintenant, pour mettre cette métaphore en code, un bon codeur écrit un code qui semble être simple et facile à faire . De nombreux exemples de Brian Kernighan dans ses livres suivent ce modèle. Une partie du "truc" consiste à proposer une conceptualisation appropriée du problème et de sa solution . Lorsque nous ne comprenons pas assez bien un problème, nous sommes plus susceptibles de compliquer nos solutions à outrance et nous ne verrons pas d'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 des explications supplémentaires sont inutiles. Un bon codeur peut également voir la vision à long terme du produit et former ses conceptualisations en conséquence.

( original )

EDIT: L'idée de base est que "la qualité du code" ne peut pas être insérée dans les règles, de la même manière que vous ne pouvez pas insérer "un bon art" ou "une bonne poésie" dans les règles de sorte que vous puissiez laisser un ordinateur déterminer "Oui, le 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.

Il n'y a vraiment aucun bon critère autre que la rapidité avec laquelle vous pouvez comprendre le code. Vous faites bien paraître votre code en trouvant le compromis parfait entre la concision et la lisibilité.

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

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

1. Le client est content
2. Vos collègues empruntent votre code comme point de départ
3. On a juste demandé au nouveau gars / femme de modifier un système que vous avez construit il y a 6 mois et il / elle ne vous a jamais posé une question.
4. Votre patron vous demande de développer de nouveaux widgets pour l’utilisation de l’équipe.
5. Vous regardez le code que vous écrivez aujourd'hui et vous vous dites: "J'aurais aimé écrire un code comme celui-ci il y a deux ans"

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

• Quel est le temps de réponse?
• Combien y a-t-il d'allers et retours vers le serveur?
• Utiliseriez-vous personnellement l'application ou pensez-vous qu'elle est maladroite?
• Voulez-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é quand il le faut. Un bon code peut être réutilisé pour réaliser des bénéfices.

Un code qui est

1. sans bug

2. réutilisable

3. indépendant

4. moins complexe

5. bien documenté

6. facile à chage

s'appelle 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, Basique, Perl, COBOL ou ASM, toute bonne programmation présente les mêmes qualités ancestrales: simplicité, lisibilité, modularité, superposition, conception, efficacité, élégance et clarté de l'efficacité, élégance et clarté

Source: MSDN

Cela vous semble 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 inquiet et j'ai commencé à confier mes préoccupations à mon superviseur. Je lui ai répété à plusieurs reprises que les motifs n'étaient pas «propres» et qu'ils devaient être «beaux» au même titre que les motifs de Dijkstra. 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 rendre mon jugement. Je n'ai pas pu lui dire! Parce que je ne pouvais pas expliquer quels principes étaient violés, mes commentaires ont été simplement ignorés et le travail a continué. Sentant qu'il doit y avoir un moyen d'expliquer et de motiver mon "goût", J'ai commencé à essayer de trouver un principe qui permettrait de distinguer les bons dessins des mauvais. Les ingénieurs sont très pragmatiques. ils peuvent admirer la beauté, mais ils cherchent l'utilité. J'ai essayé de trouver une explication à la raison pour laquelle la «beauté» était utile.

S'il vous plaît voir le reste ici .

en dehors des critères de qualité naturels du code (copier / coller minimum, pas de spaghettis, etc.), un bon code industriel doit toujours paraître un peu naïf, un peu trop bavard, 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);

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

Bon code est

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

Les exemples comprennent

• Apache Commons
• Cadre de printemps
• Cadre Hibernate

Je vais simplement aller avec "maintenable"

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

Si un lecteur ne comprend pas cette exigence simple ou n'a pas besoin d'être précisé, il ne doit pas écrire de code ...

Un bon code sera différent pour chaque personne et la langue avec laquelle elle travaille 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é?Le code du fichier est-il clairement documenté, 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 sont organisées les fonctions? Existe-t-il un schéma clair indiquant où les variables sont déclarées, ou s'agit-il d'un schéma assez aléatoire? Le code a-t-il un flux logique et évite-t-il des structures de contrôle inutiles? Est-ce que tout est clairement documenté, le code étant auto-documenté là où le besoin se fait sentir et les commentaires expriment clairement le pourquoi et / ou comment de ce que le code fait?

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 si la conception globale de l'application n'a aucun sens.

Permettez-moi de 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 pour lesquels vous vous demandez si le programmeur est allé plus loin que la programmation 101 et ceux pour lesquels vous ne comprenez absolument pas la génialité du code. Certains codes peuvent paraître très étranges au début, mais c’est 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 considérablement la vitesse. R est un excellent exemple d'une langue où c'est souvent vrai. On aime y éviter le plus de boucles possibles. En général, je considère que le code le plus rapide est le meilleur, même s'il est moins lisible. En d’autres termes, si l’amélioration est importante bien sûr et que suffisamment de commentaires sont insérés pour expliquer l’utilisation du code.

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

Alors oui, la lisibilité est importante pour un bon code. Je connais l’adagium d’Uwe Liggis: penser mal et ordinateurs ne coûtent pas cher. Mais dans mon domaine (génomique statistique), les temps de calcul d’une semaine et une utilisation de la mémoire supérieure à 40 Go ne sont pas considérés comme anormaux. Ainsi, une amélioration de deux fois la vitesse et de la moitié de la mémoire vaut beaucoup plus que ce petit peu de lisibilité.

En ce qui me concerne ... Je sais que j'écris un 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 ne passe en revue chaque bloc de code. et montrant ce qu'il fait.
Au lieu de lui dire: "Attends une minute, quoi?!" Il dit: "Oh, d'accord, je vois ce que vous avez fait là-bas."

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

Un bon code comporte de nombreuses fonctionnalités, mais la plus importante, à mon humble avis, est la lisibilité et la maintenabilité.

Votre code sera contenir des bugs, sera probablement être étendue et réutilisée, et devait - - être re- prises en compte à un moment donné - même si elle est vous re-visiter, les chances sont que vous ne serez pas la moindre idée ce que l'enfer en premier lieu, vous vous êtes rendu service et vous n’a pas mis de barrière.

Bien sûr, utilisez cet algorithme complexe, mais extrêmement efficace, mais assurez-vous de passer un peu plus de temps à le documenter, mais sinon, assurez-vous que votre code est clair et cohérent.