Peut-on définir des normes d'écriture d'un beau code ?
« Il n'y a pas de style de code correct », il faut être cohérent selon un bloggeur

0PARTAGES

8  0 
L’écriture d’un code qui permet de satisfaire les exigences fonctionnelles et de performance a toujours été la première priorité des développeurs. Au-delà de cet aspect, bon nombre de programmeurs s’attardent un peu sur le style d’écriture de leur code pour faciliter la lecture et la compréhension. Cela permet au développeur de repérer plus facilement les erreurs et également de comprendre ce qu’il essayait de faire lorsqu’il revient sur le projet quelques mois plus tard. Si en plus, d’autres ingénieurs doivent hériter du code, il est généralement conseillé d’adopter un style cohérent qui facilitera la continuité ou la réutilisation du code.

L’idée d’adopter un style d’écriture cohérent semble faire l’unanimité, mais une question se pose toutefois sur le style à adopter et à ce niveau, beaucoup de mythes demeurent. Ce qui est accepté par un développeur peut être interdit chez un autre, et ce qui est obligatoire chez l’un peut être inutile chez l’autre. Chacun avance des arguments plus ou moins pertinents pour défendre sa position, et sur Developpez.com, bien qu’on ait plusieurs fois débattu sur ce sujet, on n’a jamais pu arriver à un consensus.

Pour un bloggeur, il y a trop de mythes autour de l’écriture d’un beau code, alors que la règle semble simple : « il n'y a pas de style de code correct, tout comme il n'y a pas de bonne solution à une tâche d'ingénierie », a écrit Marc Newlin. Il pense que les nombreux guides de styles existants écrits dans l’absolu peuvent être utiles, mais manquent souvent de prendre en compte que le contexte d'un projet est aussi important que le code lui-même.

Marc Newlin s’est donc proposé, à travers son billet, de briser ces mythes au sujet de la manière d’écrire un beau code.

Pour lui, c’est une erreur de penser que l’utilisation de commentaires verbeux et d’espaces blancs font de vous un mauvais programmeur. Certains développeurs font valoir que les commentaires sont redondants, mais selon Newlin, c’est peut-être parce qu’ils oublient qu’il est plus facile de comprendre quelques phrases dans notre langue maternelle que le code directement dans un langage. Si ces derniers arrivent facilement à comprendre un code sans commentaire, ils pourraient toutefois gagner du temps à analyser la version commentée. Pour être efficace, le bloggeur pense qu’il est logique de commenter tôt et bien souvent, et les espaces viennent en compléments des commentaires pour faciliter la lecture du code.

Un autre problème auquel il s’attaque est la guerre autour des conventions de nommage. Pour Newlin, « il n’y aura jamais de gagnant, c’est une guerre inutile. Tout le monde a une préférence sur les conventions de nommage, et certains langages préfèrent massivement un style plutôt que l'autre. La seule chose qui importe est la cohérence. »

Ce qu’il propose donc lorsque vous travaillez sur un projet existant, c’est de suivre les conventions déjà en place. Et si vous débutez un nouveau projet, la logique serait de définir les conventions de nommage que vous souhaitez utiliser, et de vous tenir strictement à cela. Dans le cas où vous travaillez sur un projet dans un langage avec un guide de style, « il est bon de suivre les conventions de nommage définies dans le guide », a-t-il écrit.

Vous avez peut-être entendu certains développeurs dire que l’utilisation de bibliothèques tierces est une mauvaise chose. Là encore Marc Newlin pense qu’il s’agit d’une erreur de la part d’un développeur qui aime ressentir la fierté d’avoir écrit un code complexe en seulement 2 jours. Newlin pense que si ce dernier avait avant tout effectué une recherche sur Google, il aurait surement trouvé une bibliothèque sous licence MIT/BSD qui fait exactement ce qu’il veut, sinon mieux. Il aurait alors gagné 2 jours pour améliorer son programme, au lieu d’essayer d’avoir la propriété complète sur son code.

Pour Marc Newlin, le plus important, c’est d’écrire votre code de sorte qu’un étudiant en informatique de première année puisse le lire, un beau code se doit d’être simple. Il ajoute également qu’un programmeur éclairé va chercher à être plus productif en étant assez humble pour utiliser des bibliothèques tierces si possible. Cela lui éviterait d’écrire beaucoup. Il devrait également utiliser le plus de commentaires possibles.

Source : Blog de Marc Newlin

Et vous ?

Partagez-vous les points de vue de Marc Newlin ?

Qu'est ce qui caractérise un beau code selon vous ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 02/06/2015 à 23:18
Justement je viens de retomber sur quelques discussions Github mémorables, comme celle-ci : https://github.com/twbs/bootstrap/issues/3057

Le point-virgule a remplacé la croix de nos jours.

ne jamais utiliser la tabulation \t car l'affichage varie en fonction de l'éditeur de texte utilisé.
C'est précisément la raison pour laquelle j'utilise les tabulations. Chacun lui donne la largeur qu'il veut, et ça évite le débat inutile du nombre d'espaces.
8  2 
Avatar de Sicyons
Membre régulier https://www.developpez.com
Le 02/06/2015 à 16:17
Je dirais qu'un beau code est un code avec de belles couleurs et des polices de caractères bien choisies.

Désolé...
6  4 
Avatar de sevyc64
Modérateur https://www.developpez.com
Le 04/06/2015 à 13:10
Sauf que là, on débat pas de bon code mais de beau code. Ceux sont de choses différentes.
6  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 02/06/2015 à 16:21
Citation Envoyé par Sicyons Voir le message
Je dirais qu'un beau code est un code avec de belles couleurs et des polices de caractères bien choisies.

Désolé...

C'est pas si hors- sujet que ça

Perso j'utilise la même coloration syntaxique/Police en JAVA/C# et quelque soit L'IDE, je m'y retrouve mieux.
5  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 04/06/2015 à 2:28
Salut,

Autant le dire tout de suite, je n'ai pas lu toues les réactions, mais, selon moi :

Effectivement, l'utilisation d'une bibliothèque "éprouvée" devrait être de l'ordre du réflexe (pourquoi se faire ch..er à (mal) faire ce que d'autres ont déjà fait et qui, surtout, dispose du recul nécessaire pour assurer que ca fait les choses correctement grâce à de nombreux utilisateurs ?)

Le style de codage, je suis également totalement d'accord : il faut être cohérent au sein d'un projet, mais il n'y a pas vraiment de "bon" ni de "mauvais" style de codage. Il faut avoir assez de souplesse pour être en mesure de s'y retrouver quel que soit le style utilisé.

Il y a cependant une chose que je n'ai pas lue dans la nouvelle, mais qui me semble importante : le choix des noms (de variables, de fonctions et de types ) : plus on arrivera à exprimer clairement ce que font les choses au travers de leur nom, plus il sera facile de comprendre le code.

Enfin, je ne suis pas du tout de l'avis de l'auteur du blog en ce qui concerne les commentaires . Oui, je suis d'accord avec le fait qu'il est sans doute plus facile de comprendre deux lignes de commentaires écrits dans sa langue natale que deux lignes de code, mais il ne faut pas oublier qu'un code est quelque chose qui évolue en permanence. Le problème des commentaires, c'est qu'ils finissent très rapidement par être "désynchronisés" par rapport au code auquel il font référence, et, à ce moment là, il devient dangereux de se fier au commentaires plutôt qu'au code. Et si c'est pour -- de toutes façons -- devoir lire le code pour s'assurer qu'il fait ce que prétendent les commentaires, autant "zapper" l'étape qui consiste à lire les commentaires, cela fera toujours moins de lecture

Ceci dit, je crois personnellement qu'il y a trois types de commentaires :
  • Les cartouches (en gros, ceux qui pourraient permettre la génération automatique de documentation grâce à javadoc ou à doxygen par exemple) : qui expliquent à quoi sert une classe / une fonction / une variable, les pré et post conditions à leur utilisation, le resultat auquel on est en droit de s'attendre, les éventuelles exceptions qui seront lancées etc.
  • Les commentaire "pédagogiques" : ce sont des commentaires spécialement destinés aux "débuttants" qui permettent simplement de poursuivre une explication directement à l'intérieur du code
  • Les commentaires "paraphrasiques" : les commentaires qui se contentent de dire ce que le code fait, sans apporter la moindre plus value.


A mon sens, seules les deux premiers types de commentaires (cartouches et commentaires pédagogiques) ont réellement du sens :
  • Le cartouche parce qu'ils font référence à la partie la plus stable du projet : l'interface qui devra être utilisée pour manipuler les différentes données.
  • Les commentaires pédagogiques, au début, pour permettre d'attirer l'attention du récipiendaire sur certains apsects du langage qu'il apprend.

Quand aux commentaires qui se contentent de paraphraser le code, je suis désolé, mais, à mon sens, ils n'apportent strictement rien et pire encore: ils sont souvent plus nuisibles qu'autre chose. Trop souvent un commentaire qui paraphrase le code va être écrit pour une version bien particulière du code, mais ne sera pas mis à jour lorsque le tronçon de code auquel il fait référence sera modifié. On en arrive alors à des situations ubuesques dans lesquels le commentaire dit une chose alors que le code en dit une autre et ca, c'est réellement de nature à nous faire perdre encore plus de temps dans la compréhension du code.

Pour moi, le meilleur commentaire sera celui que l'on ne devra pas écrire : si l'on choisit correctement les noms des variables, des fonctions et des types, si l'on veille un minimum à respecter le principe de la responsabilité unique, le code devrait en permanence arriver à se suffire à lui-même et les commentaire paraphrasiques deviennent de facto inutiles
5  0 
Avatar de ustensile
Membre régulier https://www.developpez.com
Le 04/06/2015 à 9:40
Un jour, je suis tombé sur le site un peu barré mais super intéressant et instructif: Sam & Max.
Leur analyse était la suivante et je suis assez d'accord avec eux :

"un bon code est un code qui marche
un bon code est un code qui continue à marcher
un bon code est un code dont on sait pourquoi il marche,
le reste n'est que drosophyle sodomite"
5  1 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 05/06/2015 à 13:04
Citation Envoyé par koala01 Voir le message
Ceci dit, je crois personnellement qu'il y a trois types de commentaires :
  • Les cartouches (en gros, ceux qui pourraient permettre la génération automatique de documentation grâce à javadoc ou à doxygen par exemple) : qui expliquent à quoi sert une classe / une fonction / une variable, les pré et post conditions à leur utilisation, le resultat auquel on est en droit de s'attendre, les éventuelles exceptions qui seront lancées etc.
  • Les commentaire "pédagogiques" : ce sont des commentaires spécialement destinés aux "débuttants" qui permettent simplement de poursuivre une explication directement à l'intérieur du code
  • Les commentaires "paraphrasiques" : les commentaires qui se contentent de dire ce que le code fait, sans apporter la moindre plus value.
Il manque :
* Le commentaire contextualisant, le plus important. Celui qui t'explique quel est le problème à affronter (en mettant en avant les cas particuliers) et justifie le choix de la solution présentée. Généralement situé avant une classe, voire une méthode complexe. S'il ne doit y avoir qu'un seul commentaire dans le fichier, que ce soit celui-ci.

* Le commentaire explicitant, celui accolé à un code et qui explicite une information implicite, généralement un couplage entre deux fragments distants du code. "Nous avons besoin d'ajouter cette information ici car la méthode XYZ en aura besoin." Souvent cela dénote un problème du code, parfois c'était la moins pire des solutions. Et parfois il se confond avec le commentaire contextualisant quand l'information implicite est extérieure au code ("le périphérique bogue si on n'envoie pas d'abord ce code"

Quant aux cartouches ils sont très souvent inutiles pour moi (presque toujours "paraphrasique" selon ta terminologie), n'ont généralement de valeur que pour les débutants, et cet excès d'information inutile finit par masquer les rares morceaux d'information utiles puisque plus personne ne les lit. La systématicité de ces cartouches est pour moi une mauvaise pratique malheureusement répandue : la bureaucratie procure un sentiment de sécurité.
5  0 
Avatar de Angelsafrania
Membre confirmé https://www.developpez.com
Le 02/06/2015 à 17:46
Citation Envoyé par Gugelhupf  Voir le message
La couleur et la police dépendent de l'éditeur de texte utilisé.[*]L'indentation à 4 espaces, ne jamais utiliser la tabulation \t car l'affichage varie en fonction de l'éditeur de texte utilisé.[/LIST]

Mais quelle horreur 4 espaces ! Ça ne va pas du tout c'est 3 espaces qu'il faut !
La seule vrai bonne normes d'écriture d'un beau code c'est l'équipe qui développe qui la défini (comme dit dans l'article). Mais c'est frustrant d'arrivé dans un projet déjà commencé avec des normes qui ne correspondent pas à nos habitude.
Parce que ma blague sur les espaces, elle est un peu vrai, je fais mes projets avec 3 espaces, au travail avec des \t les projets que je fork ça dépens.

Ce qu'il faudrait c'est un descripteur de normes pour le projet pour qu'il soit toujours versionné avec les mêmes normes et un descripteur de normes perso sur chaque poste pour les dev l'IDE faisant les conversions automatiquement.
4  2 
Avatar de NotNow
Membre actif https://www.developpez.com
Le 02/06/2015 à 21:43
Citation Envoyé par foetus Voir le message
le strict c'est 80 colonnes
Oui, mais c'était plus avant... Maintenant, on a de grands écrans, souvent double, cette règle est un peu désuète depuis le temps non ? Surtout que desfois, en Java, on peut vite y arriver !
4  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 08/06/2015 à 11:10
Citation Envoyé par ChristianRoberge Voir le message
Toutefois, si on regarde de les listings ou les écrans, nous discriminons assez facilement le bons, des mauvais programmeurs.
Je préfère parler de bon et mauvais codes, que de bon et mauvais développeurs.

Déjà parce que l'on peut être tous amené à un moment, dans un projet et sous la pression, à créer du "code tout pourri": est-on alors automatiquement un mauvais programmeurs?
Pas forcement, on n'a juste pas été dans les meilleurs conditions pour faire du bon travail.
Même de jeunes développeurs qui pourraient être classifier trop rapidement de "mauvais programmeurs" sont dans un situation où on ne leur permet pas de s'améliorer, s'auto-former et donc se rendre meilleur.

Les revus de codes sont justement de bonne pratique pour rendre un "code tout pourri" bien meilleur.
Mais si on commence ce travail, en équipe, pas passer au pilori le développeur qui a réalisé cela, ce ne deviens pas constructif.
Aidons nous plutôt a être tous meilleur, le développement logiciel est un travail d'équipe: jouons collectif.
Malheureusement, cela viens trop souvent de certaines directions qui ne laissent pas suffisamment de temps aux équipes pour faire un travail de qualité.

Après, il y a toujours de personne, que je ne classifierais pas de "mauvais programmeurs" mais de personne ayant aucun capacité à se remettre en question.
Ce n'est pas un problème lier à notre métier mais à la personnalité de ces développeurs.
Là, en effet, ce manque de qualité nécessaire dans l'industrie du génie logiciel est préjudiciable à la fois pour les projets que pour les personnes elle-mêmes.
4  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web