Que signifie écrire du “ bon code ”? [fermé]

Il ny a vraiment pas de bons critères autres que la vitesse à laquelle vous pouvez comprendre le code. Vous donnez une belle apparence à votre code en trouvant le compromis parfait entre concision et lisibilité.

Les « WTF » par minute « (ci-dessus) est vrai mais ce nest quun corollaire de la règle plus générale. Plus il y a de WTF, plus la compréhension est lente.

Commentaires

• @rmx: define " faire le travail eh bien "
• Et bien, que la méthode RemoveCustomer supprime en fait le client sans se tromper. Vous pouvez passer des heures à le rendre joli, mais cela ne signifie pas que cela fonctionne réellement. ' La vitesse à laquelle vous pouvez comprendre le code ' nest pas le seul critère pour ' un bon code ' est ce que je ' dis.
• @rmx: mais être sans bogue est sous-entendu, nest pas ' t-il? Si votre code ' ne fait pas correctement le travail, il ' nest pas (encore) code.
• @ rmx: en fait, non. Si votre code est facile à comprendre, alors en conclusion il ' est facile à comprendre sil le fait ' mal. OTOH, si ' est difficile à comprendre, il ' est difficile à comprendre si cest le cas '.
• @rmx: PS en termes simples, votre décrément () est un WTF classique et donc il ralentit la compréhension des parties de code où cette fonction est utilisée

Vous savez que vous écrivez du bon code quand …

1. Le client est content
2. Des collègues empruntent votre code comme point de départ
3. On vient de dire au tout nouveau type / fille dapporter des modifications à un système que vous avez construit il y a 6 mois et il / elle ne vous a jamais posé de question
4. Votre patron vous demande de développer de nouveaux widgets pour léquipe à utiliser
5. Vous regardez le code que vous écrivez aujourdhui et vous vous dites « Jaurais aimé avoir écrit un code comme celui-ci il y a deux ans »

Comment allez-vous mesurer si le code est bon …

• Quel est le temps de réponse?
• Combien dallers-retours vers le serveur fait-il?
• Utiliseriez-vous personnellement lapplication ou pensez-vous quelle est maladroite?
• La construiriez-vous de la même manière la prochaine fois?

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

Commentaires

• " Le client est content " est orthogonal à ceci.
• @TRA – Si le client est satisfait, cela signifie que vous avez compris les exigences et fourni une solution quil attendait.
• un code sûr mais un mauvais code peut faire la même chose.

Un code qui est

1. sans bogue

2. réutilisable

3. indépendant

4. moins complexe

5. bien documenté

6. facile à modifier

sappelle un bon code.

Un bon programme fonctionne parfaitement et ne comporte aucun bogue. Mais quelles qualités internes produisent une telle perfection ?. Ce nest 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, toute bonne programmation présente les mêmes qualités ancestrales: simplicité, lisibilité, modularité , superposition, design, efficacité, élégance et clarté efficacité, élégance et clarté

Source: MSDN

Commentaires

• Simplicité, lisibilité, élégance et clarté sont la même chose. La modularité et la superposition ne sont que des méthodes pour rendre votre code clair et élégant. La seule chose qui reste dans la liste est lefficacité, qui est en quelque sorte implicite, et en plus il sagit souvent de compromis entre efficacité et clarté.
• Vérifiez ceci: goo.gl/hdQt8
• Le code peut être sans bogue?
• Non, il peut ' t. (Pratiquement)
• Efficient devrait être ajouté à votre liste. Speed isn ' t necess Cest souvent un indicateur principal dun bon code, mais un bon code ne devrait ' être inutilement lent ou gaspilleur.

Cela vous semble-t-il familier?

Philips ma donné lopportunité de regarder la conception dun nouveau produit. Au fur et à mesure de son évolution, je suis devenu de plus en plus mal à laise et jai commencé à confier mes préoccupations à mon superviseur. Je lui ai répété à plusieurs reprises que les créations n’étaient pas «propres» et qu’elles devaient être «belles» de la même manière que les créations de Dijkstra étaient belles. Il na pas trouvé que cétait un commentaire utile.Il ma rappelé que nous étions des ingénieurs, pas des artistes. Dans son esprit, jexprimais simplement mon goût et il voulait savoir quel critère jutilisais pour faire mon jugement. Je nai pas pu lui dire! Comme je ne pouvais pas expliquer quels principes étaient violés, mes commentaires ont tout simplement été ignorés et le travail a continué. Sentant quil devait y avoir un moyen dexpliquer et de motiver mon «goût», jai commencé à essayer de trouver un principe qui distinguerait les bons dessins des mauvais. Les ingénieurs sont très pragmatiques; ils peuvent admirer la beauté, mais ils recherchent lutilité. Jai essayé de trouver une explication de lutilité de la « beauté ».

Veuillez voir le reste ici .

Commentaires

• Puisque le lien dans le message de @mlvljr ' est rompu , voici un lien vers la page Google Livres: books.google.co.in/…
• @balajeerc Merci (jai également corrigé le lien, donc il pointe vers une version hébergée par Springer du même pdf) 🙂

Hormis les critères de qualité du code naturel (copier / coller minimum, pas de spaghetti, etc.) un bon code industriel doit toujours paraître 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); 

Commentaires

• Mais est-ce que do_not_create = false signifie « passer false comme argument do_not_create pour quil sera créé »ou« pas s false comme argument do_create pour quil ne soit pas créé »? Dans une langue où vous pouvez utiliser des noms darguments, je préférerais cache.get (key:i, create: false); i += 1;.

Peut-être quune réponse illustrant le contraire aiderait (en plus, cest une excuse pour obtenir XKCD ici).

Un bon code est

• simple à comprendre,
• facile à maintenir ,
• nessaie pas de résoudre tous les problèmes, seul celui qui est en jeu
• dure longtemps sans que les développeurs cherchent des alternatives

Les exemples incluent

• Apache Commons
• Spring framework
• Hibernate framework

Jirai simplement 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 en a besoin, alors ce lecteur ne devrait 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 envisagé être un bon code. Généralement, lorsque jaborde un projet, je recherche les éléments suivants:

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

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

Permettez-moi de ne pas être daccord 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 saisissez absolument pas la gentillesse du code. Certains codes peuvent sembler très étranges. premier, mais est en fait une solution très inventive à un problème difficile. Le second ne devrait 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 de langage où cela est souvent vrai. On aime y éviter autant que possible les boucles for.En général, je considère que le code le plus rapide est le meilleur code même sil est moins lisible. Autrement dit, si lamélioration est substantielle, bien sûr, et que suffisamment de commentaires sont insérés pour expliquer ce que fait le code.

Encore 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 lutilisation de la mémoire: il y a juste plus dobjets créés. Dans certains cas, lutilisation intelligente de la mémoire rend le code encore moins lisible. Mais si vous jonglez avec des gigaoctets de séquences dADN par exemple, la mémoire est un facteur crucial. Encore une fois, je considère que le code le moins gourmand en mémoire est le meilleur code, quelle que soit sa lisibilité.

Alors oui, la lisibilité est importante pour un bon code. Je connais ladagium dUwe Liggis: penser que ça fait mal et que les ordinateurs sont bon marché. Mais dans mon domaine (génomique statistique), les temps de calcul dune semaine et lutilisation de la mémoire de plus de 40 Go ne sont pas considérés comme anormaux. Donc, une amélioration de deux fois la vitesse et la moitié de la mémoire vaut beaucoup plus que ce petit plus de lisibilité.

Commentaires

• Pas de règle / règles sans exception
• Permettez-moi de ne pas être daccord avec votre désaccord: vous dites que dans votre domaine la vitesse est très importante et dites quelle est plus importante que la lisibilité. Je ne suis pas daccord, vous devriez vous efforcer dutiliser le bon équilibre. Si la vitesse nest pas nécessaire, par exemple pour une interface de haut niveau, vous préférerez peut-être quelque chose de facile à entretenir, si la vitesse est nécessaire, je suis daccord avec vous. Plutôt que des règles strictes, il vaut mieux utiliser le bon sens et vous devriez quand même éviter une optimisation prématurée.
• @BlueTrin Pourquoi ne pas à la fois compiler par le cerveau ces codez sources de haute performance, et aussi documenter lenfer de ce que ' est en cours là-bas (juste là dans les commentaires)?

n ce qui me concerne … Je sais que jécris du bon code quand un collègue qui travaille sur un autre projet arrive et est capable de me lancer et de comprendre ce que je fais sans que je passe en revue chaque bloc de code et montrant ce quil 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 na 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 nest pas une bonne façon de le faire, mais je vais juste devoir le faire de cette façon pour le moment. Je « me rappellerai de laméliorer plus tard … »

Il y a beaucoup de fonctionnalités du « bon » code , mais le plus important, à mon humble avis, est la lisibilité et la maintenabilité.

Votre code contiendra des bogues, sera probablement étendu et réutilisé, et devrait être retravaillé à un moment donné – même si cest vous le revisitez, il y a de fortes chances que vous ne sachiez pas ce que vous avez fait en premier lieu, à faire une faveur et ne mettez pas de barrières sur le chemin.

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, faites votre code clair et cohérent.