À quoi ressemble le code d'un bon programmeur? [fermé]

Je suis un programmeur amateur (j'ai commencé avec VBA pour rendre Excel plus rapide) 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 le «bon»? Je ne suis pas un professionnel donc je n'ai pas grand-chose à comparer. Qu'est-ce qui fait un meilleur programmeur? Est-ce:

• Ils ont une meilleure compréhension de tous les objets / classes / méthodes dans une langue donnée?
• Leurs programmes sont-ils plus efficaces?
• La conception de leurs programmes est bien meilleure en termes de meilleure documentation, bon 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 son code par rapport au mien? Par exemple, je lis des livres comme «Professional ASP.NET» de Wrox press. Les exemples de code de ce livre sont-ils de «classe mondiale»? Est-ce le summum? Est-ce qu'un programmeur de haut niveau examinerait ce code et penserait que c'était du bon code?

La liste ci-dessous n'est pas exhaustive, mais ce sont les choses auxquelles j'ai pensé en examinant votre question.

• Un bon code est bien organisé. Les données et les opérations dans les classes s'emboîtent. Il n'y a pas de dépendances superflues entre les classes. Cela ne ressemble pas à des "spaghettis".

• Les bons commentaires de code expliquent pourquoi les choses sont faites et non ce qui est fait. Le code lui-même explique ce qui est fait. Le besoin de commentaires doit être minime.

• Un bon code utilise des conventions de dénomination significatives pour tous les objets sauf les plus transitoires. le nom de quelque chose indique quand et comment utiliser l'objet.

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

• Un bon code n'est pas «intelligent». Il fait les choses de manière simple et évidente.

• Un bon code est développé en petites unités de calcul faciles à lire. Ces unités sont réutilisées tout au long du code.

Je ne l'ai pas encore lu, mais le livre que j'ai l'intention de lire sur ce sujet est Clean Code 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, indentent religieusement et commentent le cas échéant.

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

La troisième chose que vous remarquerez, après avoir un peu dérangé le code, c'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 faits pour construire leur architecture de code.

En ce qui concerne les livres, je n'ai pas vu beaucoup de livres où le code pourrait ê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 du code que les humains peuvent comprendre.

dit Nough.

Personnellement, je vais devoir citer "The Zen of Python" de Tim Peters. Cela indique aux programmeurs Python à quoi devrait ressembler leur code, mais je trouve que cela s'applique à pratiquement tout le code.

Beau est mieux que laid.
L'explicite vaut mieux que l'implicite.
Le simple vaut mieux que le complexe.
Complexe vaut mieux que compliqué.
Plat est mieux que niché.
Clairsemé vaut mieux que dense.
La lisibilité compte.
Les cas spéciaux ne sont pas assez spéciaux pour enfreindre les règles.
Bien que l'aspect pratique l'emporte sur la pureté.
Les erreurs ne devraient jamais passer silencieusement.
À moins d'être explicitement réduit au silence.
Face à l'ambiguïté, refusez la tentation de deviner.
Il devrait y avoir une - et de préférence une seule - façon évidente de le faire.
Bien que cette manière ne soit pas évidente au début, sauf si vous êtes néerlandais.
C'est mieux que jamais.
Bien que jamais ne soit souvent mieux quedès maintenant.
Si l'implémentation 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 point de logique et vous pourrez tirer de nombreuses 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, modifier et refactoriser pour le lecteur.

Une suite sur le corollaire:

Le lecteur sera vous au temps n à compter de la date de création du code. Le gain de l'écriture de code pour le lecteur est une fonction monotone croissante de n. Un lecteur qui regarde votre code pour la première fois est indiqué par n == infini.

En d'autres termes, plus l'écart de temps entre le moment où vous avez écrit le code et le moment où vous revisitez le code est grand, plus vous apprécierez vos efforts pour écrire pour le lecteur. De plus, toute personne à qui vous confiez votre code tirera un grand avantage du code écrit avec le lecteur en premier lieu.

Un deuxième corollaire:

Un code écrit sans considération pour le lecteur peut être inutilement difficile à comprendre ou à utiliser. Lorsque la considération pour le lecteur descend en dessous d'un certain seuil, le lecteur tire moins de valeur du code que la valeur acquise 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 que c'est une question difficile à répondre. 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 contient 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 des choses différentes pour différentes personnes. Ce que je pourrais qualifier de bon code, quelqu'un d'autre pourrait détester. Un bon code aura quelques traits communs que je pense avoir identifiés ci-dessus.

La meilleure chose que vous puissiez faire est de vous exposer au code. Regardez le code des autres. Les projets Open Source sont une bonne source pour cela. Vous trouverez du bon code et du mauvais code. Plus vous l'examinez, mieux vous reconnaîtrez ce que vous considérez comme 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 arriverez à votre propre style et cela changera avec le temps. Il n'y a personne ici qui puisse agiter une baguette et dire ce qui est bon et que tout le reste est mauvais.

Lisez le livre Code Complete. Cela explique beaucoup d'idées sur la façon de structurer le code et les raisons de le faire. Le lire devrait court-circuiter votre temps pour acquérir l'expérience nécessaire pour distinguer le bien 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é pendant près de 10 ans et ayant travaillé avec d'autres, je peux dire sans préjugé qu'il n'y a pas de différence entre un bon programmeur et un code de programmeur moyen

Tous les programmeurs à un niveau compétent:

• Commenter correctement
• Structurer efficacement
• Documentez proprement

Une fois, j'ai entendu un collègue dire: " J'ai toujours été très logique et rationnel. Je pense que c'est pourquoi 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 l'écriture d'un programme.

Le programmeur expert, comprend les règles, mais aussi leur contexte. Cela les amène finalement à proposer de nouvelles idées et implémentations, la marque d'un programmeur expert. La programmation est finalement une forme d'art.

En bref, le code d'un bon 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 en peu de temps avec un minimum de réflexion, quel que soit le langage de programmation utilisé. Que le code soit en Java, Python, C ++ ou Haskell, un code bien écrit est compréhensible par des personnes qui ne programment même pas dans ce langage particulier.

Certaines caractéristiques d'un code facile à lire sont des méthodes bien nommées, l'absence de "trucs" et une "optimisation" alambiquée, les classes sont bien conçues, pour n'en nommer 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 Stack Overflow. Il est écrit en JavaScript, un langage que je n'ai guère utilisé. Pourtant, en raison du style de codage et des commentaires inclus, ainsi que de la structuration du code lui-même, c'était assez compréhensible, et j'ai pu naviguer dans le code en quelques minutes.

Un livre qui m'a ouvert les yeux en ce qui concerne la lecture du code d'un bon programmeur est Beautiful Code . Il contient de nombreux articles écrits par des auteurs de divers projets de programmation dans divers langages de programmation. Pourtant, quand je l'ai lu, je pouvais comprendre ce que l'auteur écrivait dans son code malgré le fait que je n'ai même jamais programmé dans cette langue particulière.

Peut-être ce que nous devrions garder à l'esprit, c'est que la programmation est aussi une question de communication, non seulement avec l'ordinateur mais avec les gens , donc un bon code de programmeur est presque comme un livre bien écrit, qui peut communiquer au lecteur sur les idées qu'il veut véhiculer. .

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

tout le reste 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'aurez aucun mal à comprendre ce que fait le code lors de la première lecture du code écrit par un bon programmeur professionnel.

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

Il s'agit essentiellement d'un livre rempli de bonnes pratiques de programmation en termes de fonctionnalité et de style.

[Réponse purement subjective]
Pour moi, un 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 (c'est-à-dire des colonnes, de l'indentation, même des noms de variables de même longueur!), De la couleur (noms de classe, noms de variables, commentaires, etc.) font tous ce que j'aime voir comme une "belle" image qui peut me rendre soit très fier, soit 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 "Clean Code" de Bob Martin.

"Beautiful Code" a été très acclamé il y a quelques années.

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

Peut-être que "The Pragmatic Programmer" serait également utile.

%

Je voulais juste ajouter mes 2 cents ... commentaires dans votre code - et votre code lui-même, en général - devrait dire ce que fait votre code, maintenant comment il le fait. Une fois que vous avez le concept de code «client», qui est du code qui appelle un autre code (l'exemple le plus simple est le code qui appelle une méthode), vous devriez toujours être plus préoccupé de rendre votre code compréhensible du point de vue du «client». Au fur et à mesure que votre code grandit, vous verrez que c'est ... euh, bien.

Beaucoup d'autres choses sur le bon code concernent les sauts mentaux que vous ferez (certainement, si vous faites attention) ... 99% d'entre eux ont à voir avec un peu plus de travail maintenant pour vous épargner une tonne de travailler plus tard, et réutilisabilité. Et aussi de bien faire les choses: je veux presque toujours courir dans l'autre sens plutôt que d'utiliser des expressions régulières, mais chaque fois que j'y entre, je vois pourquoi tout le monde les utilise dans chaque langue dans laquelle je travaille (elles sont abstruses, mais travailler et ne pourrait probablement pas être mieux).

Quant à savoir s'il faut regarder des livres, je dirais certainement pas d'après mon expérience. Regardez les API, les frameworks et les conventions de code et le code des autres et utilisez votre propre instinct, et essayez de comprendre pourquoi les choses sont comme elles sont et quelles sont les implications des choses. La chose que le code dans les livres ne fait presque jamais est de planifier l'imprévu, ce qui est le but de la vérification des erreurs. Cela ne rapporte que lorsque quelqu'un vous envoie un e-mail et vous dit: "J'ai eu l'erreur 321" au lieu de "hé, l'application est en panne, yo".

Un bon code est écrit avec l'avenir à l'esprit, à la fois du point de vue du programmeur et du point de vue de l'utilisateur.

C'est assez 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 «ASP.NET professionnel», mais je serais surpris si c'est mieux que OK. 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 récemment un article ACM sur le beau code. Il semble que l'accent soit mis sur la facilité de lecture / compréhension. Je qualifierais cela de «facile à lire / comprendre par les experts du domaine». Les très bons programmeurs ont tendance à utiliser les meilleurs algorithmes (au lieu d'algorithmes naïfs et faciles à comprendre O (n ^ 2)) pour des problèmes donnés, ce qui peut être difficile à suivre, si vous n'êtes pas familier avec l'algorithme, même si le bon programmer donne une référence à l'algorithme.

Personne n'est parfait, y compris de bons programmeurs, mais leur code a tendance à viser :

1. Exactitude et efficacité avec des algorithmes éprouvés (au lieu de hacks naïfs et adhoc)
2. Clarté (commentaire d'intention en référence à des algorithmes non triviaux)
3. Exhaustivité pour couvrir les bases (convention de codage, gestion des versions, documentation, tests unitaires, etc.)
4. Succinct (SEC)
5. Robustesse (résilient aux entrées arbitraires et aux perturbations des demandes de changement)

J'appuie la recommandation pour le "code propre" de l'oncle bob. mais vous voudrez peut-être jeter un coup d'œil à 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 il fonctionne.

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

Lorsque vous êtes dactylographe, vous devez toujours être élégant dans votre travail, avoir une structure et une «grammaire» appropriée est très important. Maintenant, la conversion en "programmation" -typage obtiendrait le même résultat.

Structure

commentaires

Régions

Je suis un ingénieur logiciel, ce qui signifie qu'au cours de mes études, j'ai rencontré de nombreux langages différents, mais ma programmation "ressent" toujours la même chose, tout comme mon écriture sur fekberg.wordpress.com, j'ai une façon "spéciale" de taper.

Maintenant, en programmant différentes applications et dans différents langages, tels que Java, C #, Assembler, C ++, C, je suis arrivé au "standard" d'écriture que j'aime.

Je vois tout comme des «boîtes» ou des régions et chaque région a ses explications en commentant. Une région peut être une «personne de classe» et à l'intérieur de cette région, j'ai quelques méthodes pour les propriétés, que je peux appeler des «méthodes d'accès» ou autres, et chaque propriété et région a ses propres commentaires explicatifs.

C'est très important, je vois toujours mon code que je fais, comme "faisant partie d'une API", lors de la création d'une structure d'API et l'élégance est TRÈS importante.

Penses-y. Lisez également mon article sur Communication issues when adapting outsourcingce qui explique en gros comment un mauvais code peut entrer en conflit, Enterpret comme vous le souhaitez: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/

Un bon code est facile à comprendre, facile à maintenir et facile à ajouter. Idéalement, il est également aussi efficace que possible sans sacrifier d'autres indicateurs.

Un bon code pour moi est quelque chose de simple à comprendre mais sophistiqué. Les choses qui vous font dire "wow, bien sûr, pourquoi n'y ai-je pas pensé de cette façon?". Un très bon code n'est pas difficile à comprendre, il résout simplement le problème en question de manière simple (ou de manière récursive, si c'est encore plus simple).

Un bon code est l'endroit où vous savez ce que fait la méthode à partir du nom. Un mauvais code est l'endroit où vous devez déterminer ce que fait le code, pour donner un sens au nom.

Le bon code est l'endroit où, si vous le lisez, vous pouvez comprendre ce qu'il fait en peu de temps plus qu'il n'en faut pour le lire. Un mauvais code est l'endroit où vous finissez par le regarder pendant des siècles en essayant de déterminer ce qu'il fait.

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

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 n'ont vraiment aucun rapport avec son objectif.

Un bon code est généralement un ensemble d'outils simples pour effectuer des tâches simples (assemblées de manière bien organisée pour effectuer des tâches plus sophistiquées). Le mauvais code a tendance à être d'énormes outils polyvalents, faciles à casser et difficiles à utiliser.

Le code est le reflet des compétences et de 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. À quel point ce sera évolutif? À quel point ce sera pratique si je ne suis pas celui qui maintient ce code? Dans quelle mesure le code sera-t-il réutilisable, de sorte que quelqu'un d'autre faisant des choses similaires puisse réutiliser le code et ne pas le réécrire. Que faire quand quelqu'un d'autre essaie de comprendre le code que j'ai écrit.

Lorsqu'un programmeur a cet état d'esprit, tout le reste se met bien en place.

Remarque: une base de code est travaillée par de nombreux programmeurs au fil du temps et il n'y a généralement pas de désignation spécifique de base de code pour un programmeur. Par conséquent, un bon code est le reflet de toutes les normes de l'entreprise et de la qualité de sa main-d'œuvre.

(J'utilise "il" ci-dessous car 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 coderai pour moi-même à l'avenir quand j'aurai tout oublié de cette tâche, pourquoi j'y travaillais, quels étaient les risques et même comment cela le code était censé fonctionner. "

En tant que tel, son code doit:

1. Travail (peu importe la rapidité avec laquelle le code parvient à la mauvaise réponse. Il n'y a pas de crédit partiel dans le monde réel).
2. Expliquez comment il sait que ce code fonctionne. C'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 pour ligne, le code de test est plus précieux que le code fonctionnel si pour aucune autre raison que cela n’explique "ce code fonctionne, voici comment il doit ê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 elle doit être faite (et rappelez-vous, c'est «hérité» au moment où il quitte votre bureau).

D'un autre côté, je crois que le bon programmeur ne devrait jamais faire ces choses:

1. Observez le formatage. Il existe de nombreux IDE, éditeurs et jolies imprimantes qui peuvent formater le code exactement selon les préférences standard ou personnelles que vous jugez appropriées. J'utilise Netbeans, j'ai configuré les options de format une fois et appuyez sur alt-shift-F de temps en temps. Décidez de l'apparence du code, configurez votre environnement et laissez l'outil faire le travail.
2. Observez les conventions de dénomination au détriment de la communication humaine. Si une convention de dénomination vous amène à nommer vos classes "IElephantProviderSupportAbstractManagerSupport" plutôt que "Zookeeper", changez la norme avant de rendre la tâche 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 réside actuellement sur son clavier. S'il y a une erreur ou une erreur, il doit d'abord se tourner vers lui-même.
5. Oubliez que ce qui se passe revient. Tout travail qu'il fait maintenant pour rendre son code plus accessible aux futurs lecteurs lui profitera presque certainement directement (car qui va être la première personne invitée à regarder son code? Il l'est).

1. Ça marche
2. Il a des tests unitaires qui prouvent que cela fonctionne

Le reste est de la glace ...

• Le meilleur code a une certaine élégance que vous reconnaissez dès que vous le voyez.
• Il a l'air conçu, avec soin et attention aux détails. Il est évidemment produit avec quelqu'un avec talent et a un art à ce sujet - on pourrait dire qu'il a l'air sculpté et poli, plutôt que rugueux et prêt.
• C'est cohérent et se lit facilement.
• Il est divisé en petites fonctions hautement cohésives qui font chacune une chose et la font bien.
• C'est un couplage minimal, ce qui signifie que les dépendances sont peu nombreuses et strictement contrôlées, généralement par ...
• Les fonctions et les classes ont des dépendances sur des abstractions plutôt que sur des implémentations.

Ironiquement , le mieux le programmeur le moins indispensable , il / elle devient parce que le code produit est mieux maintenable par quiconque (comme indiqué par consentement général par Eran Galperin).

Mon expérience dit que le contraire est également vrai. Le pire le programmeur le plus difficile à maintenir son / son code est, donc plus indispensable , il / elle devient, puisque aucune autre âme ne peut comprendre les énigmes produites.

J'ai un bon exemple:

Lisez le code source de GWT (google web takeit), vous verrez que tous les imbéciles le comprennent (certains livres anglais sont plus difficiles à lire que ce code).