À quoi ressemble le code d'un bon programmeur ?

Question

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. C'est mon premier message et je m'excuse pour la nature subjective de ma question.

Une facette de la programmation qui m'a toujours frustré est de savoir à quoi ressemble le "bon". Je ne suis pas un professionnel et j'ai donc peu de points de comparaison. Qu'est-ce qui fait un meilleur programmeur ? Est-ce que c'est :

• 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 documentation, bon choix de noms pour les fonctions, etc.

En d'autres termes, si je devais regarder le code d'un programmeur professionnel, quelle serait la première chose que je remarquerais dans 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 ? N'importe quel programmeur de haut niveau regarderait-il ce code et penserait-il que c'est du bon code ?

Answer 1

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

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

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

• Un bon code utilise des conventions de dénomination significatives pour tous les objets, sauf les plus éphémères. Le nom d'un objet renseigne sur le moment et la manière de l'utiliser.

• 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 directe 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 le suivant Code propre par Robert C. Martin.

Answer 2

La première chose que vous remarquerez, c'est que leur code suit une structure cohérente. style de codage . Ils écrivent toujours leurs blocs de structure de la même façon, les indentent religieusement et les commentent lorsque c'est nécessaire.

La deuxième chose que vous remarquerez est que leur code est segmenté en petites méthodes/fonctions ne dépassant pas quelques dizaines de lignes tout au plus. Ils utilisent également des noms de méthodes autodescriptifs et leur code est généralement très lisible.

La troisième chose que vous remarquerez, après avoir manipulé un peu le code, c'est que la logique est facile à suivre, facile à modifier - et donc facile à maintenir.

Ensuite, vous aurez besoin d'une certaine connaissance et expérience des techniques de conception de logiciels pour comprendre les choix spécifiques qu'ils ont faits en construisant l'architecture de leur code.

En ce qui concerne les livres, je n'en ai pas vu beaucoup dont 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 qui ne reflètent pas des situations plus complexes.

Answer 3

Citer Fowler, résumer la lisibilité :

N'importe quel idiot peut écrire un code qu'un ordinateur peut comprendre.
Les bons programmeurs écrivent du code que les humains peuvent comprendre.

Assez parlé.

Answer 4

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

Le beau est mieux que le laid.
L'explicite est préférable à l'implicite.
La simplicité est préférable à la complexité.
Le complexe est mieux que le compliqué.
Le plat est meilleur que l'imbriqué.
Le clairsemé est préférable au dense.
La lisibilité compte.
Les cas particuliers ne sont pas assez particuliers pour enfreindre les règles.
Bien que l'aspect pratique batte la pureté.
Les erreurs ne doivent jamais passer en silence.
Sauf si elle est explicitement réduite au silence.
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 forcément évidente au premier abord, à moins d'être néerlandais.
Mieux vaut maintenant que jamais.
Bien que jamais soit souvent mieux que droite 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 idée géniale - il faut en faire plus !

Answer 5

Le code est de la poésie.

En partant de ce point de logique, vous pouvez dériver un grand nombre des qualités souhaitables du code. Plus important encore, observez que le code est lu bien plus qu'il n'est écrit, donc écrivez du code pour le lecteur. Réécrivez, renommez, éditez et remaniez pour le lecteur.

Un corollaire de suivi :

Le lecteur sera vous au temps n de la date de création du code. Le gain de l'écriture du 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'intervalle de temps entre le moment où vous avez écrit le code et celui où vous le révisez est important, plus vous apprécierez vos efforts pour écrire pour le lecteur. De même, toute personne à qui vous confiez votre code tirera un grand bénéfice d'un code écrit en tenant compte du lecteur.

Un deuxième corollaire :

Un code écrit sans considération pour le lecteur peut être inutilement difficile à comprendre ou à utiliser. Lorsque la prise en compte du lecteur tombe en dessous d'un certain seuil, le lecteur tire moins de valeur du code que celle obtenue en le réécrivant. Lorsque cela se produit, le code précédent est jeté et, tragiquement, une grande partie du travail est répétée lors de la réécriture.

Un troisième corollaire :

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