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

Le , par Michael Guilloux, Chroniqueur Actualités
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de vampirella vampirella - Membre éclairé https://www.developpez.com
le 02/06/2015 à 14:46
Ma foi, tout ceci n'est que du bon sens, toujours utile de rappeler puisqu'il parait que nous, les ingénieurs dév, sommes particulièrement susceptibles
Avatar de mikrethor mikrethor - Membre du Club https://www.developpez.com
le 02/06/2015 à 15:35
Plein de bon sens tout ça.

Il n'y a rien de pire pour un développeur de pester contre un code mal écrit et de se rendre conpte qu'on est celui qui l'a écrit.
Ne pas oublier lors du développement d'une application qu'en général le temps de maintenance sera plus important que le temps de réalisation initial.
Avatar de Sicyons 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é...
Avatar de dfiad77pro dfiad77pro - Membre éprouvé 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.
Avatar de Gugelhupf Gugelhupf - Modérateur https://www.developpez.com
le 02/06/2015 à 16:35
La couleur et la police dépendent de l'éditeur de texte utilisé.

Pour moi il y a des caractéristiques d'un "beau code" :
  • Le respect des conventions d'écriture du langage (ex: pour Java, pour C#, pour PHP)
  • L'indentation à 4 espaces, ne jamais utiliser la tabulation \t car l'affichage varie en fonction de l'éditeur de texte utilisé.
Avatar de NotNow NotNow - Membre actif https://www.developpez.com
le 02/06/2015 à 16:57
D'ailleurs, en parlant de beau code, c'est quand qu'on brule la "K&R style" ?

Pas taper
Avatar de tanatiel tanatiel - Membre régulier https://www.developpez.com
le 02/06/2015 à 17:11
Effectivement du bon sens et il faut toujours se rappeler certains principe comme KISS

Et pour ce qui est de l'utilisation de bibliothèques tierces, je ne peurx qu'appuyer si celles-ci ne sont pas un obscur projet connu par deux personnes dans le monde. On a toujours avantage à utiliser des standards connus et partagés, la maintenabilité en est grandement améliorée.
Avatar de Angelsafrania 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.
Avatar de jdddeschamps jdddeschamps - Membre régulier https://www.developpez.com
le 02/06/2015 à 18:08
Personnellement j'utilise la norme aviva en C# : https://csharpguidelines.codeplex.com/
Il est indispensable de choisir soigneusement des Guidelines avant de débuter un projet et de s'y tenir fermement surtout si plusieurs codeurs travaillent sur le même projet.
Avatar de AoCannaille AoCannaille - Membre chevronné https://www.developpez.com
le 02/06/2015 à 18:43
Citation Envoyé par jdddeschamps  Voir le message
Personnellement j'utilise la norme aviva en C# : https://csharpguidelines.codeplex.com/
Il est indispensable de choisir soigneusement des Guidelines avant de débuter un projet et de s'y tenir fermement surtout si plusieurs codeurs travaillent sur le même projet.

Interessant ce pdf, je le garde sous le coude

par contre, tout est toujours sujet à débat.

En l'occurence :
AV1545 Don’t use if-else statements instead of a simple (conditional) assignment 
Express your intentions directly. For example, rather than
Code C# : Sélectionner tout
1
2
3
4
5
6
7
8
9
bool pos; 
if (val > 0)  
{  
 pos = true;  
}  
else  
{  
 pos = false;  
}
write
Code C# : Sélectionner tout
1
2
  
bool pos = (val > 0); // initialization
Or instead of
Code C# : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
  
string result;  
  
if (someString != null)  
{  
 result = someString;  
}  
else  
{  
 result = “Unavailable”;  
}  
  
return result;
write
Code C# : Sélectionner tout
return someString ?? “Unavailable”;

Je suis d'accord avec cette règle (et en généralisation, j'aime bien l'opérateur ternaire sur des condition/résultat simples et direct), mais la plupart de mes collègues sont complètement contre.
Contacter le responsable de la rubrique Accueil