À quoi ressemble un code de bon programmeur?

Je suis un programmeur amateur (qui a commencé avec VBA pour améliorer Excel) et j’ai travaillé avec VB.NET / C # .NET et j’essaie d’apprendre ADO.NET.

Une facette de la programmation qui m’a toujours frustré est à quoi ressemble «bon»? Je ne suis pas un professionnel, donc j’ai peu à comparer. Qu’est-ce qui fait un meilleur programmeur? Est-ce:

  • Ils ont une meilleure compréhension de tous les objects / classes / méthodes dans une langue donnée?
  • Leurs programmes sont plus efficaces?
  • La conception de leurs programmes est bien meilleure en termes de documentation, de choix de noms pour les fonctions, etc.

En d’autres termes, si je devais regarder le code d’un programmeur professionnel, quelle est la première chose que je remarquerais à propos de leur code par rapport au mien? Par exemple, je lis des livres comme «Professional ASP.NET» par Wrox Press. Les exemples de code de ce livre sont-ils de «classe mondiale»? Est-ce le pinacle? Est-ce qu’un programmeur de premier plan regarderait ce code et penserait que c’était du bon code?

La liste ci-dessous n’est pas exhaustive, mais c’est ce que j’ai pensé en examinant votre question.

  • Un bon code est bien organisé. Les données et les opérations dans les classes vont ensemble. Il n’y a pas de dépendances externes entre les classes. Cela ne ressemble pas à des “spaghettis”.

  • De bons commentaires sur le code expliquent pourquoi les choses ne sont pas faites. Le code lui-même explique ce qui est fait. La nécessité de commentaires devrait être minimale.

  • Un bon code utilise des conventions de dénomination significatives pour tous les objects, sauf les plus transitoires. le nom de quelque chose est informatif sur quand et comment utiliser l’object.

  • Un bon code est bien testé. Les tests servent de spécification exécutable du code et d’exemples d’utilisation.

  • Un bon code n’est pas “intelligent”. Il fait les choses de manière simple et évidente.

  • Un bon code est développé dans de petites unités de calcul faciles à lire. Ces unités sont réutilisées dans tout le code.

Je ne l’ai pas encore lu, mais le livre que j’ai l’intention de lire sur ce sujet est le code propre de Robert C. Martin.

La première chose que vous remarquerez est que leur code suit un style de codage cohérent. Ils écrivent toujours leurs blocs de structure de la même manière, les indentent religieusement et les commentent le cas échéant.

La deuxième chose que vous remarquerez est que leur code est segmenté en petites méthodes / fonctions ne dépassant pas deux douzaines de lignes au maximum. Ils utilisent également des noms de méthodes auto-descriptives et leur code est généralement très lisible.

La troisième chose que vous remarquerez, après avoir un peu déconcerté avec le code, est que la logique est facile à suivre, facile à modifier et donc facilement maintenable.

Après cela, vous aurez besoin de connaissances et d’expérience dans les techniques de conception de logiciels pour comprendre les choix spécifiques qu’ils ont pris en construisant leur architecture de code.

En ce qui concerne les livres, je n’ai pas vu beaucoup de livres où le code pouvait être considéré comme “de classe mondiale”. Dans les livres, ils essaient surtout de présenter des exemples simples, qui peuvent être pertinents pour résoudre des problèmes très simples, mais ne reflètent pas des situations plus complexes.

Citant Fowler, résumant la lisibilité:

N’importe quel imbécile peut écrire du code qu’un ordinateur peut comprendre.
Les bons programmeurs écrivent le code que les humains peuvent comprendre.

dit Nough.

Personnellement, je devrai citer “The Zen of Python” de Tim Peters. Il indique aux programmeurs Python à quoi devrait ressembler leur code, mais je trouve que cela s’applique essentiellement à tout le code.

Beautiful est mieux que moche.
Explicit vaut mieux qu’implicite.
Simple vaut mieux que complexe.
Complexe vaut mieux que compliqué.
Flat est mieux que niché.
La densité est meilleure que la densité.
La lisibilité compte.
Les cas spéciaux ne sont pas assez spéciaux pour enfreindre les règles.
Bien que pratique bat la pureté.
Les erreurs ne devraient jamais passer en silence.
Sauf si explicitement réduit au silence.
Face à l’ambiguïté, refusez la tentation de deviner.
Il devrait y avoir un – et de préférence une seule – méthode évidente pour le faire.
Bien que cela ne soit pas évident au premier abord, sauf si vous êtes néerlandais.
Maintenant c’est mieux que jamais.
Bien que jamais, c’est souvent mieux que maintenant.
Si la mise en œuvre est difficile à expliquer, c’est une mauvaise idée.
Si la mise en œuvre est facile à expliquer, cela peut être une bonne idée.
Les espaces de noms sont une excellente idée – faisons-en plus!

Le code est la poésie.

Commencez à partir de ce sharepoint logique et vous pouvez tirer beaucoup des qualités souhaitables du code. Plus important encore, observez que le code est lu beaucoup plus qu’il n’est écrit, donc écrivez du code pour le lecteur. Réécrire, renommer, éditer et refactoriser pour le lecteur.

Un corollaire suivant:

Le lecteur sera vous à l’instant n de la date de création du code. Le gain d’écriture du code pour le lecteur est une fonction monotone croissante de n. Un lecteur qui examine votre code pour la première fois est indiqué par n == infinity.

En d’autres termes, plus l’écart entre le moment où vous avez écrit le code et la révision du code est grand, plus vous apprécierez vos efforts pour écrire pour le lecteur. De même, toute personne à qui vous confiez votre code bénéficiera grandement du code écrit avec le lecteur comme principale considération.

Un deuxième corollaire:

Le code écrit sans considération pour le lecteur peut être inutilement difficile à comprendre ou à utiliser. Lorsque la considération pour le lecteur devient inférieure à un certain seuil, le lecteur tire moins de valeur du code que la valeur obtenue en réécrivant le code. Lorsque cela se produit, le code précédent est jeté et, tragiquement, beaucoup de travail est répété pendant la réécriture.

Un troisième corollaire:

Le corollaire deux est connu pour se répéter plusieurs fois dans un cercle vicieux de code mal documenté suivi de réécritures forcées.

Je programme depuis 28 ans et je trouve difficile de répondre à cette question. Pour moi, un bon code est un package complet. Le code est proprement écrit, avec des noms de variables et de méthodes significatifs. Il a des commentaires bien placés qui commentent l’intention du code et ne font pas que régurgiter le code que vous pouvez déjà lire. Le code fait ce qu’il est censé faire de manière efficace, sans gaspiller de ressources. Il doit également être écrit dans un souci de maintenabilité.

L’essentiel est que cela signifie différentes choses pour différentes personnes. Ce que je pourrais qualifier de bon code, quelqu’un d’autre pourrait détester. Un bon code aura des traits communs que je pense avoir identifiés ci-dessus.

La meilleure chose à faire est de vous exposer au code. Regardez le code des autres personnes. Les projets Open Source sont une bonne source pour cela. Vous trouverez le bon code et le mauvais code. Plus vous le regardez, mieux vous reconnaîtrez ce que vous définissez comme étant un bon code et un mauvais code.

En fin de compte, vous serez votre propre juge. Lorsque vous trouvez des styles et des techniques que vous aimez, adoptez-les, au fil du temps, vous inventerez votre propre style et cela changera avec le temps. Il n’y a personne ici qui puisse brandir une baguette et dire ce qui est bon et ce qui est mauvais.

Lisez le livre Code Complet. Cela explique beaucoup d’idées sur la façon de structurer le code et les raisons de le faire. La lecture devrait court-circuiter votre temps à acquérir l’expérience nécessaire pour bien dire du mal.

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1229267173&sr=8-1

Ayant moi-même programmé depuis près de 10 ans et ayant travaillé avec d’autres, je peux dire sans parti pris qu’il n’ya pas de différence entre un bon programmeur et un code de programmeur moyen.

Tous les programmeurs à un niveau compétent:

  • Commenter correctement
  • Structure efficace
  • Document propre

Un jour, j’ai entendu un collègue dire: ” J’ai toujours été très logique et rationnel. Je pense que c’est pour ça que j’aime développer

C’est à mon avis l’esprit d’un programmeur moyen. Celui qui voit le monde en termes de règles et de logique et obéit finalement à ces règles lors de la conception et de la rédaction d’un programme.

Le programmeur expert comprend les règles, mais aussi leur contexte. Cela les amène à venir avec de nouvelles idées et mises en œuvre, la marque d’un programmeur expert. La programmation est finalement une forme d’art.

En résumé, un bon code de programmeur peut être lu et compris.

À mon avis, le code d’ un bon programmeur est indépendant du langage ; Un code bien écrit peut être lu et compris rapidement en un minimum de reflection, quel que soit le langage de programmation utilisé. Que le code soit en Java, Python, C ++ ou Haskell, le code bien écrit est compréhensible par les personnes qui ne programment même pas dans cette langue particulière.

Certaines caractéristiques du code faciles à lire sont des méthodes bien nommées, l’absence de “trucs” et une “optimisation” compliquée, les classes sont bien conçues, pour n’en citer que quelques-unes. Comme d’autres l’ont mentionné, le style de codage est cohérent, succinct et simple .

Par exemple, l’autre jour, je regardais le code de TinyMCE pour répondre à l’une des questions sur le débordement de la stack. Il est écrit en JavaScript, un langage que j’ai peu utilisé. Cependant, en raison du style de codage et des commentaires inclus, ainsi que de la structuration du code lui-même, cela était assez compréhensible et j’ai pu naviguer dans le code en quelques minutes.

Un livre qui m’a beaucoup ouvert les yeux sur la lecture du code du bon programmeur est Beautiful Code . Il a de nombreux articles écrits par les auteurs de divers projets de programmation dans divers langages de programmation. Pourtant, quand je le lisais, je pouvais comprendre ce que l’auteur écrivait dans son code, même si je n’avais jamais programmé dans cette langue.

Peut-être devrions-nous garder à l’esprit que la programmation concerne aussi la communication, non seulement avec l’ordinateur mais aussi avec les gens , alors le bon code du programmeur est presque comme un livre bien écrit, qui peut communiquer au lecteur les idées qu’il veut transmettre. .

  • Facile à lire
  • facile à écrire
  • facile à maintenir

tout le rest est en filigrane

Un bon code doit être facilement compris.
Cela devrait être bien commenté.
Les parties difficiles devraient être encore mieux commentées.

Un bon code est lisible. Vous n’auriez aucune difficulté à comprendre ce que le code fait lors de la première lecture du code écrit par un bon programmeur professionnel.

Je voulais juste append mes 2 cents … commentaires dans votre code – et votre code lui-même, en général – devrait indiquer ce que fait votre code, maintenant comment il le fait. Une fois que vous avez le concept de code «client», qui appelle un autre code (par exemple, le code appelle une méthode), vous devez toujours vous soucier de rendre votre code compréhensible du sharepoint vue du «client». Au fur et à mesure que votre code grandit, vous verrez que c’est … bon, bien.

Beaucoup d’autres choses sur le bon code concernent les sauts mentaux que vous allez faire (certainement, si vous faites attention) … 99% d’entre eux ont à faire un peu plus de travail maintenant pour vous épargner une tonne de travailler plus tard, et réutilisable. Et aussi pour bien faire les choses: j’ai presque toujours envie de tourner dans l’autre sens plutôt que d’utiliser des expressions régulières, mais chaque fois que je les utilise, je vois pourquoi tout le monde les utilise dans travailler et ne pourrait probablement pas être mieux).

Quant à savoir s’il faut regarder des livres, je dirais certainement pas dans mon expérience. Examinez les API, les frameworks, les conventions de code et le code des autres utilisateurs et utilisez vos propres instincts, et essayez de comprendre pourquoi les choses sont telles qu’elles sont et quelles sont les implications des choses. La chose que le code dans les livres ne fait presque jamais est de planifier pour le non planifié, ce qui est la raison d’être de la vérification des erreurs. Cela ne vaut que lorsque quelqu’un vous envoie un email et dit: “J’ai eu l’erreur 321” au lieu de “Hé, l’application est cassée, yo”.

Un bon code est écrit en fonction du futur, tant du sharepoint vue du programmeur que du sharepoint vue de l’utilisateur.

Plutôt que de répéter les bonnes suggestions de tous, je vous suggérerai plutôt de lire le livre Code Complete de Steve McConnell.

Essentiellement, c’est un livre rempli de bonnes pratiques de programmation, à la fois pour la fonctionnalité et le style.

[Réponse purement subjective]
Pour moi, le bon code est une forme d’art, tout comme une peinture. Je pourrais aller plus loin et dire que c’est en fait un dessin qui comprend des caractères, des couleurs, une “forme” ou une “structure” de code, et tout cela étant si lisible / performant. La combinaison de la lisibilité, de la structure (colonnes, indentation, même des noms de variables de même longueur!), De la couleur (noms de classes, noms de variables, commentaires, etc.) fait tout ce que j’aime voir comme une “belle” image. me rendre très fier ou très détestable de mon propre code.

(Comme dit précédemment, réponse très subjective. Désolé pour mon anglais.)

J’appuie la recommandation du “Code propre” de Bob Martin.

“Beautiful Code” a été acclamé il y a quelques années.

Tous les livres de McConnell valent la peine d’être lus.

Peut-être que “le programmeur pragmatique” serait utile aussi.

%

Ceci est très bien répondu dans le livre de Fowler, “Refactoring”, c’est l’absence de toutes les “odeurs” qu’il décrit tout au long du livre.

Je n’ai pas vu ‘Professional ASP.NET’, mais je serais surpris si c’est mieux que ça. Voir cette question pour certains livres avec un très bon code. (Cela varie bien sûr, mais la réponse acceptée est difficile à battre.)

Cela semble être (devrait être) une FAQ. Il y a un article d’ACM sur le beau code récemment. Il semble y avoir beaucoup d’emphase sur la facilité de lecture / compréhension. Je qualifierais cela de “facile à lire / à comprendre par les experts du domaine”. Vraiment de bons programmeurs ont tendance à utiliser les meilleurs algorithmes (au lieu de simples algorithmes naïfs et faciles à comprendre) pour tout problème donné, ce qui peut être difficile à suivre, même si le bon programmeur donne une référence à l’algorithme.

Personne n’est parfait, y compris les bons programmeurs, mais leur code tend à:

  1. Exactitude et efficacité avec des algorithmes éprouvés (au lieu de hacks naïfs et ad hoc)
  2. Clarté (commentaire pour intention en référence à des algorithmes non sortingviaux)
  3. Complétude pour couvrir les bases (convention de codage, gestion des versions, documentation, tests unitaires, etc.)
  4. Succinctness (DRY)
  5. Robustesse (résiliente aux entrées arbitraires et à la perturbation des demandes de changement)

J’appuie la recommandation pour le “code propre” d’oncle bob. mais vous voudrez peut-être jeter un oeil à http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091 car je pense que cela traite un peu mieux votre question spécifique. Un bon code devrait sortir de la page et vous dire ce qu’il fait / comment cela fonctionne.

Jeff Atwood a écrit un article intéressant sur la façon dont les codeurs sont la première référence des dactylographes: http://www.codinghorror.com/blog/archives/001188.html

Lorsque vous êtes un dactylographe, vous devez toujours être élégant dans votre travail, il est très important d’avoir une structure et une “grammaire” appropriées. La conversion de ceci en typage “programmation” obtiendrait le même résultat.

Structure

commentaires

Les régions

Je suis un ingénieur logiciel, ce qui signifie que pendant mes études, j’ai rencontré de nombreuses langues différentes, mais ma programmation se sent toujours la même, comme mon écriture le fait sur fekberg.wordpress.com, j’ai une manière “spéciale” de taper.

Programmation maintenant de différentes applications et dans différentes langues, telles que Java, C #, Assembler, C ++, C, je suis arrivé au “standard” de l’écriture que j’aime.

Je vois tout comme des «boîtes» ou des régions et chaque région a ses explications. Une région peut être une “personne de classe” et à l’intérieur de cette région, j’ai deux méthodes pour les propriétés, que je peux appeler “méthodes d’access”, et chaque propriété et région a ses propres explications.

Ceci est très important, je vois toujours mon code que je fais, car “faire partie d’un api”, lors de la création d’une structure API et de l’élégance est très important.

Penses-y. Lisez également mon article sur Communication issues when adapting outsourcing qui explique en gros à quel point le code peut entrer en conflit, Enterpret à votre guise: externalisation /

Un bon code est facile à comprendre, facile à entretenir et à append. Idéalement, il est aussi efficace que possible sans sacrifier d’autres indicateurs.

Pour moi, le code est simple à saisir mais sophistiqué. Les choses qui vous font “wow, bien sûr, pourquoi n’y ai-je pas pensé de cette façon?”. Vraiment un bon code n’est pas difficile à comprendre, il résout simplement le problème en question de manière directe (ou récursive, si cela est encore plus simple).

Bon code est l’endroit où vous savez ce que la méthode fait du nom. Le mauvais code est l’endroit où vous devez déterminer ce que le code fait, pour donner un sens au nom.

Un bon code est l’endroit où, si vous le lisez, vous pouvez comprendre ce qu’il fait en moins de temps qu’il ne faut pour le lire. Le mauvais code est l’endroit où vous finissez par le regarder pendant des années en essayant de le faire.

Un bon code a des choses nommées de manière à rendre inutiles les commentaires sortingviaux.

Un bon code a tendance à être court.

Un bon code peut être réutilisé pour faire ce qu’il fait ailleurs, car il ne repose pas sur des éléments qui ne sont pas vraiment liés à son objective.

Un bon code est généralement un ensemble d’outils simples permettant d’effectuer des tâches simples (regroupés de manière bien organisée pour effectuer des tâches plus sophistiquées). Un code erroné a tendance à être un énorme outil multi-usage facile à casser et à utiliser.

Le code reflète les compétences et l’état d’esprit d’un programmeur. Les bons programmeurs ont toujours un œil sur l’avenir – comment le code fonctionnera lorsque les exigences ou les circonstances ne sont pas exactement ce qu’elles sont aujourd’hui. Comment sera scalabale? À quel point cela sera-t-il pratique quand je ne suis pas celui qui maintient ce code? Comment le code sera-t-il réutilisable, de sorte que quelqu’un d’autre qui fasse des choses similaires puisse réutiliser le code et ne pas l’écrire à nouveau. Et quand quelqu’un d’autre essaie de comprendre le code que j’ai écrit?

Lorsqu’un programmeur a cet état d’esprit, toutes les autres choses se mettent bien en place.

Remarque: De nombreux programmeurs travaillent sur une base de code au fil du temps et il n’ya généralement pas de désignation spécifique de base de code pour un programmeur. Un bon code reflète donc toutes les normes de l’entreprise et la qualité de son personnel.

(J’utilise “il” ci-dessous parce que c’est la personne que j’aspire à être, parfois avec succès).

Je crois que le cœur de la philosophie d’un bon programmeur est qu’il pense toujours: «Je me code à l’avenir quand j’aurai oublié toute cette tâche, pourquoi j’y travaillais, quels étaient les risques et même comment le code était censé fonctionner. ”

En tant que tel, son code doit:

  1. Travailler (peu importe la rapidité avec laquelle le code donne la mauvaise réponse. Il n’ya pas de crédit partiel dans le monde réel).
  2. Expliquez comment il sait que ce code fonctionne. Ceci est une combinaison de documentation (javadoc est mon outil de choix), de gestion des exceptions et de code de test. Dans un sens très réel, je crois que ligne par ligne, le code de test a plus de valeur que le code fonctionnel si, pour aucune autre raison qu’il n’explique “ce code fonctionne, c’est comment il devrait être utilisé, et c’est pourquoi je devrais obtenir payé.”
  3. Être maintenu. Le code mort est un cauchemar. La maintenance du code hérité est une corvée, mais il faut le faire (et rappelez-vous que c’est un inheritance au moment où il quitte votre bureau).

Par contre, je pense que le bon programmeur ne devrait jamais faire ça:

  1. Observer le formatage. Il y a beaucoup d’EDI, d’éditeurs et de jolies imprimantes qui peuvent formater le code selon les préférences standard ou personnelles que vous estimez appropriées. J’utilise Netbeans, je configure les options de format une fois et appuie de temps en temps sur alt-shift-F. Décidez comment vous voulez que le code apparaisse, configurez votre environnement et laissez l’outil faire le travail.
  2. Observer les conventions de nommage au désortingment de la communication humaine. Si une convention de dénomination vous amène à nommer vos classes “IElephantProviderSupportAbstractManagerSupport” plutôt que “Zookeeper”, modifiez la norme avant de la rendre plus difficile pour la personne suivante.
  3. Oubliez qu’il travaille en équipe avec des êtres humains réels.
  4. Oubliez que la principale source d’erreurs de codage est de restr assis sur son clavier dès maintenant. S’il y a une erreur ou une erreur, il doit d’abord se regarder.
  5. Oubliez que ce qui circule arrive. Tout travail qu’il fait actuellement pour rendre son code plus accessible aux futurs lecteurs lui sera certainement très utile (car qui sera la première personne à examiner son code? Il l’est).
  1. Ça marche
  2. Il a des tests unitaires qui prouvent que cela fonctionne

Le rest est de la cerise …

  • Le meilleur code a une certaine élégance que vous reconnaissez dès que vous le voyez.
  • Il est conçu avec soin et attention aux détails. Il est évidemment produit avec quelqu’un de talent et a un art à ce sujet – vous pourriez dire qu’il semble sculpté et poli, plutôt que rugueux et prêt.
  • C’est cohérent et lit facilement.
  • Il est divisé en petites fonctions hautement cohérentes, chacune faisant une chose et le faisant bien.
  • Il est couplé de manière minimale, ce qui signifie que les dépendances sont peu nombreuses et ssortingctement contrôlées, généralement par …
  • Les fonctions et les classes ont des dépendances sur les abstractions plutôt que sur les implémentations.

Ironiquement, plus le programmeur est performant, moins il devient indispensable, car le code produit est mieux entretenu par quiconque (comme indiqué par le consentement général d’Eran Galperin).

Mon expérience montre que le contraire est également vrai. Plus le programmateur est mauvais, plus il est difficile de maintenir son code, plus il / elle devient indispensable , car aucune autre âme ne peut comprendre les énigmes produites.

J’ai un bon exemple:

Lire GWT (google web takenit) Le code source, vous verrez que chaque imbécile le comprend (certains livres en anglais sont plus difficiles à lire que ce code).