À quoi ressemble un bon code de programmeur?
Je suis un programmeur amateur (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, j'ai donc peu de choses à 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 un langage donné?
- Leurs programmes sont plus efficaces?
- La conception de leurs programmes est bien meilleure en termes de meilleure documentation, bon choix de noms pour les fonctions etc.?
Autrement dit, si je regardais le code d'un programmeur professionnel, quelle serait la première chose que je remarquerais au sujet de leur code par rapport au mien? Par exemple, j'ai lu 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 regarderait ce code et penserait que c'était un 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 étrangères entre les classes. Cela ne ressemble pas à des "spaghettis".
De 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 devrait ê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 est informatif sur 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 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 Clean Code par 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, tirent 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 quelques dizaines de lignes au maximum. Ils utilisent également des noms de méthode auto-descriptifs et généralement leur code est très lisible.
La troisième chose que vous remarquerez, après avoir un peu mal tourné avec 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 pris en construisant 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 pourraient être utiles pour résoudre des problèmes très simples, mais ne reflètent pas des situations plus complexes.
Citant Fowler, résumant la lisibilité:
Tout imbécile peut écrire du code qu'un ordinateur peut comprendre.
Les bons programmeurs écrivent du code que les humains peuvent comprendre.
dit-il.
Personnellement, je vais devoir citer "Le Zen de Python" par Tim Peters. Il indique à Python programmeurs à quoi devrait ressembler leur code, mais je trouve qu'il s'applique à pratiquement tout le code.
Beau, c'est mieux que laid.
Explicite vaut mieux qu'implicite.
Simple est mieux que complexe.
Complexe vaut mieux que compliqué.
L'appartement est meilleur que l'emboîtement.
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 la praticité l'emporte sur la pureté.
Les erreurs ne doivent jamais passer silencieusement.
Sauf silence explicite.
Face à l'ambiguïté, refusez la tentation de deviner.
Il devrait y avoir une - et de préférence une seule - manière évidente de le faire.
Bien que cette voie ne soit pas évidente au début, sauf si vous êtes néerlandais.
Maintenant c'est mieux que jamais.
Bien que jamais ne soit souvent meilleur que à droite maintenant.
Si l'implémentation est difficile à expliquer, c'est une mauvaise idée.
Si la mise en œuvre est facile à expliquer, ce peut être une bonne idée.
Les espaces de noms sont une excellente idée de klaxon - faisons-en plus!
Le code est de la poésie.
Commencez à partir de ce point de logique et vous pouvez dériver 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éécrivez, renommez, éditez et refactorisez pour le lecteur.
Un corollaire à suivre:
Le lecteur sera vous à l'instant n à partir de la date de création du code. Le bénéfice 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 l'écriture du code et la révision du code est grand, plus vous apprécierez vos efforts pour écrire pour le lecteur. En outre, toute personne à qui vous remettez votre code bénéficiera grandement du code écrit avec le lecteur comme étant la 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 tombe en dessous d'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 que c'est une question difficile à répondre. Pour moi, un bon code est un package complet. Le code est écrit proprement, avec des noms de variable et de méthode significatifs. Il a des commentaires bien placés qui commentent l'intention du code et ne régurgite pas seulement le code que vous pouvez déjà lire. Le code fait ce qu'il est censé faire de manière efficace, sans gaspiller les ressources. Il doit également être rédigé 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 que quelqu'un d'autre détesterait. Un bon code aura des 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 un bon code et un mauvais code. Plus vous le regardez, mieux vous reconnaîtrez ce que vous jugez être du bon et du mauvais code.
En fin de compte, vous serez votre propre juge. Lorsque vous trouvez des styles et des techniques que vous aimez les adopter, au fil du temps, vous arriverez à votre propre style et cela changera au fil du temps. Il n'y a personne ici qui puisse brandir 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. La lecture devrait court-circuiter votre temps pour acquérir l'expérience nécessaire pour distinguer le bien du mal.
Ayant moi-même programmé pendant près de 10 ans maintenant et ayant travaillé avec d'autres, je peux dire sans parti pris que 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
- Documenter proprement
J'ai entendu une fois 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 conduit finalement à proposer de nouvelles idées et implémentations, la marque d'un programmeur expert. La programmation est finalement une forme d'art.
- Facile à lire
- facile à écrire
- facile à maintenir
tout le reste est en filigrane
En résumé, un bon code de programmeur peut être lu et compris.
À mon avis, un bon code de 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 gens 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" compliqué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 jetais un œil au code de TinyMCE pour répondre à l'une des questions sur Stack Overflow. Il est écrit en JavaScript, un langage que j'ai à peine utilisé. Pourtant, en raison du style de codage et des commentaires qui y sont inclus, ainsi que de la structure du code lui-même, il était assez compréhensible, et j'ai pu naviguer dans le code en quelques minutes.
Un livre qui m'a vraiment ouvert les yeux en ce qui concerne la lecture du bon code du programmeur est Beau code . Il contient de nombreux articles écrits par les auteurs de divers projets de programmation dans différents 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 que nous devons garder à l'esprit que la programmation concerne également la communication, non seulement avec l'ordinateur mais aussi avec les personnes , donc un bon code de programmeur est presque comme un livre bien écrit, qui peut communiquer au lecteur les idées qu'il souhaite transmettre.
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 aucun mal à comprendre ce que fait le code lors de la première lecture d'un code écrit par un bon programmeur professionnel.
Plutôt que de répéter les excellentes suggestions de tout le monde, je vous suggérerai plutôt de lire le livre Code Complete par Steve McConnell
Il s'agit essentiellement d'un livre rempli de meilleures pratiques de programmation pour la fonctionnalité et le style.
Je voulais juste ajouter mes 2 cents ... les commentaires dans votre code - et votre code lui-même, en général - devraient dire ce que fait votre code, maintenant comment il le fait. Une fois que vous avez le concept de code "client", qui est un code qui appelle un autre code (l'exemple le plus simple est le code qui appelle une méthode), vous devriez toujours être plus soucieux 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 la réutilisabilité. Et aussi pour 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 vais, je vois pourquoi tout le monde les utilise dans toutes les langues dans lesquelles je travaille (ils sont abstrus, mais fonctionnent et ne pourraient probablement pas être mieux).
Concernant l'opportunité de regarder des livres, je dirais certainement pas d'après mon expérience. Regardez les API et les cadres et les conventions de code et le code des autres 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, c'est de planifier l'imprévu, c'est à cela que sert la vérification des erreurs. Cela ne paie que lorsque quelqu'un vous envoie un e-mail et dit: "J'ai eu l'erreur 321" au lieu de "hé, l'application est cassée, yo."
Un bon code est écrit en pensant à l'avenir, tant du point de vue du programmeur que de celui de l'utilisateur.
[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 lisibilité, de structure (c.-à-d. Colonnes, indentation, même noms de variables de même longueur!), Couleur (noms de classe, noms de variables, commentaires, etc.) font tous ce que j'aime voir comme une "belle" image qui peut 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é très apprécié il y a quelques années.
N'importe quel livre de McConnell mérite d'être lu.
Peut-être que "The Pragmatic Programmer" serait également utile.
%
j'appuie la recommandation pour le "code propre" de l'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 de votre question spécifique un peu mieux. un bon code devrait sauter 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 dactylographes: http://www.codinghorror.com/blog/archives/001188.html
Lorsque vous êtes dactylographe, vous devez toujours être élégant dans votre travail, avoir une strucutre et une "grammaire" appropriée est très important. Maintenant, la conversion de ce type en "programmation" entraînerait le même résultat.
Structure
Commentaires
Régions
Je suis un moteur logiciel, ce qui signifie qu'au cours de mes études, j'ai rencontré de nombreuses langues différentes, mais ma programmation "se sent" toujours la même, 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 #, Assembleur, C++, C, je suis arrivé au "standard" d'écriture que j'aime.
Je vois tout comme des "cases" ou des régions et chaque région a son explication des commentaires. Une région peut être "Classe Personne" et à l'intérieur de cette région, j'ai quelques méthodes pour les propriétés, que je peux appeler "méthodes d'accès" ou autres et chaque propriété et région a sa propre explication des commentaires.
Ceci est très important, je vois toujours mon code que je fais, comme "faire partie d'une API", lors de la création d'une structure API et l'élégance est [~ # ~] très [~ # ~] important.
Penses-y. Lisez également mon article sur Communication issues when adapting outsourcing ce qui explique grossièrement à quel point le mauvais code peut entrer en conflit, Enterpret comme vous le souhaitez: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/ =
Ceci 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 'Professional ASP.NET', 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 n article ACM sur le beau code récemment. 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 faciles à comprendre O (n ^ 2)) pour tout problème donné, ce qui pourrait être difficile à suivre, si vous n'êtes pas familier avec l'algorithme, même si le bon le programmeur donne une référence à l'algorithme.
Personne n'est parfait, y compris les bons programmeurs, mais leur code a tendance à s'efforcer de:
- Exactitude et efficacité avec des algorithmes éprouvés (au lieu de hacks naïfs et adhoc)
- Clarté (commentaire d'intention en référence à des algorithmes non triviaux)
- Exhaustivité pour couvrir les bases (convention de codage, versioning, documentation, tests unitaires, etc.)
- Succinct (SEC)
- Robustesse (résilient aux entrées arbitraires et interruption des demandes de changement)
Un bon code est facile à comprendre, à entretenir et à 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 à saisir mais sophistiqué. Les choses qui vous font partir, "wow, bien sûr, pourquoi n'y ai-je pas pensé de cette façon?". Un code vraiment bon n'est pas difficile à comprendre, il résout simplement le problème en question de manière directe (ou de manière récursive, si c'est encore plus simple).
Un 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 fait le code, 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 n'en faut pour le lire. Le 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 ne sont vraiment pas liés à son objectif.
Un bon code est généralement un ensemble d'outils simples pour effectuer des tâches simples (assemblés 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 à 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. Comment ce sera scalabale? Est-ce que ce sera pratique lorsque ce n'est pas moi qui maintiendra ce code? Comment le code sera réutilisable, afin que quelqu'un d'autre faisant des choses similaires puisse réutiliser le code et ne pas le réécrire. Et quand quelqu'un d'autre essaie de comprendre le code que j'ai écrit.
Quand un programmeur a cet état d'esprit, toutes les autres choses se mettent 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. Un bon code est donc le reflet de toutes les normes de l'entreprise et de la qualité de son personnel.
(J'utilise "il" ci-dessous parce que c'est la personne que je 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 suis en train de coder 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. "
À ce titre, son code doit:
- Travail (peu importe la vitesse à laquelle le code parvient à la mauvaise réponse. Il n'y a pas de crédit partiel dans le monde réel).
- Expliquez comment il sait que ce code fonctionne. Il s'agit d'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 est plus précieux que le code fonctionnel si, pour aucune autre raison qu'il n'explique "ce code fonctionne, voici comment il devrait être utilisé, et c'est pourquoi je devrais obtenir payé."
- Être maintenu. Le code mort est un cauchemar. La maintenance du code hérité est une corvée mais cela doit être fait (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:
- 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, je configure les options de formatage une fois et je tape de temps en temps sur alt-shift-F. Décidez de l'apparence du code, configurez votre environnement et laissez l'outil faire le gros du travail.
- Obséder sur les conventions de dénomination au détriment de la communication humaine. Si une convention de dénomination vous mène sur la voie de la dénomination de vos classes "IElephantProviderSupportAbstractManagerSupport" plutôt que "Zookeeper", modifiez la norme avant de la rendre plus difficile pour la prochaine personne.
- Oubliez qu'il travaille en équipe avec de vrais êtres humains.
- Oubliez que la principale source d'erreurs de codage se trouve actuellement sur son clavier. S'il y a une erreur ou une erreur, il doit d'abord se tourner vers lui.
- Oubliez que ce qui se passe arrive. Tout travail qu'il fait maintenant pour rendre son code plus accessible aux futurs lecteurs lui sera presque certainement bénéfique directement (car qui va être la première personne à consulter son code? Il l'est).
- Le meilleur code a une certaine élégance que vous reconnaissez dès que vous le voyez.
- Il semble conçu avec soin et attention aux détails. Il est évidemment produit avec quelqu'un de talent et a un art à ce sujet - on pourrait dire qu'il a l'air sculpté et poli, plutôt que brut et prêt.
- Il 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.
- Il est peu couplé, 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 abstractions plutôt que sur les implémentations.
J'ai un bon exemple:
Lisez le code source de GWT (google web hadit), vous verrez que chaque imbécile le comprend (certains livres en anglais sont plus difficiles à lire que ce code).
Si vous écrivez du code C++, il y a un très bon livre avec d'excellentes normes de codage auquel nous nous référons à uni et qui s'appelle: "Normes de codage C++: 101 règles, lignes directrices et meilleures pratiques"par Herb Sutter, Andrei Alexandrescu et Bjarne Stroustrup.
Ironiquement, le meilleur programmeur le moins indispensable il/elle devient parce que le code produit est mieux maintenable par n'importe qui (comme indiqué par le consentement général d'Eran Galperin).
Mon expérience montre que le contraire est également vrai. Le pire le programmeur le plus difficile à maintenir son code est, donc plus indispensable il/elle devient, car aucune autre âme ne peut comprendre les énigmes produites.
- Ça marche
- Il a des tests unitaires qui prouvent que cela fonctionne
Le reste est la cerise ...